[금융고객을 위한 Resiliency in the Cloud] 최근 대규모 장애 사태 여파에 따른 DR 동향과 최신 관련 규제 업데이트

© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon Confidential and Trademark.
금융 고객을 위한 RESILIENCY IN THE CLOUD WORKSHOP 2023
FINANCIAL SERVICES |
F I N A N C I A L S E R V I C E S
DR 동향과 규제 및 DR 계획
Byeong-eok Kang, Solutions Architect
Dongho Lee, FSI Compliance Specialist

Agenda
• 시작하기 전에
• IT DR 관련 규제
• DR Overview
• DR 구성 계획
• DR 테스트
• DR to Resiliency
2

시작하기 전에
- 개념정리
3

재해관리 관련 정의(#1)
4
• 재난 – 생명·신체·재산 피해를 주거나 줄 수 있는 것( 출처: 재난 및 안전관리 기본법 ( 약칭: 재난안전법 ) 제 3조의 1 )
ü 자연재난: 태풍, 홍수, 호우(豪雨), 강풍, 풍랑, 해일(海溢), 대설, 한파, 낙뢰, 가뭄, 폭염, 지진, 황사(黃砂), 조류(藻類) 대발생,
조수(潮水), 화산활동, 소행성ㆍ유성체 등 자연우주물체의 추락ㆍ충돌, 그 밖에 이에 준하는 자연현상으로 인하여 발생하는 재해
ü 사회재난: 화재ㆍ붕괴ㆍ폭발ㆍ교통사고(항공사고 및 해상사고를 포함한다)ㆍ화생방사고ㆍ환경오염사고 등으로 인하여
발생하는 대통령령으로 정하는 규모 이상의 피해와 국가핵심기반의 마비, 「감염병의 예방 및 관리에 관한 법률」에 따른 감염병
또는 「가축전염병예방법」에 따른 가축전염병의 확산, 「미세먼지 저감 및 관리에 관한 특별법」에 따른 미세먼지 등으로 인한 피해
- 전산망 침투, 테러, 파업, 폭동, 방화, 폭발물 설치, 전력공급중단, 통신망 두절 등
ü 기술적 장애 – 전산시스템 등 하드웨어의 이상, 소프트웨어의 파괴 등
• 재해 – 재난으로 인하여 발생하는 피해
• 재해경감활동 – 재해경감활동관리체계를 통해 재해경감활동계획을 수립하고 이행하는 총체적인 관리
프로세스
• 재해경감활동계획 – 재난으로부터 피해를 최소화하기 위하여 수립하는 전략계획, 경감계획,
사업연속성확보계획, 대응계획 및 복구계획 – 출처: 재해경감을 위한 기업의 자율활동 지원에 관한 법률 ( 약칭:
기업재해경감법 )

재해관리 관련 정의(#2)
5
• 업무연속성계획 – 재해 또는 사고 발생 시 업무에 미치는 영향을 파악, 피해를 최소화하기 위해 수립하는
데이터 백업, 재해복구 및 침해 사고대응 훈련계획, 출구 전략 – 출처 :금융부문 클라우드 이용가이드
• 기업 재해경감활동계획 수립기준 – 재해경감활동관리체계 구축, 운영 및 실행, 교육과 훈련, 감시 및 검토,
유지관리 및 지속적인 개선 등의 표준화된 절차와 원칙 규정
• BCP vs DRP 개념
• BCP - 기업의 운영이 중단되어도 중요한 기능을 유지하고 빠르게 복구할 수 있는 대처 계획입니다. BCP는 기업의 재난 대처 시스템을
구축하고, 재난 발생 시 재난 대처 팀이 구축한 계획에 따라 빠르게 대처할 수 있는 구조를 마련하는 것을 목적
• DRP - 재난 발생 시 IT 시스템이나 데이터를 복구하는 계획입니다. DRP는 IT 시스템이나 데이터가 손상되어도 빠르게 복구할 수 있는
구조를 마련하는 것을 목적
• BCP는 기업의 재난 대처 전체 계획을 말하고, DRP는 기업의 IT 시스템 및 데이터 복구 계획

IT DR 관련 규제
6

금융 IT DR 규제
7
1. 전자금융거래법 - 전자금융거래의 안전성과 신뢰성을 확보
2. 전자금융감독규정 - 금융회사의 정보시스템 안전성 및 안정적 운영을 위한 내용을 규정
제1조(목적) 이 법은 전자금융거래의 법률관계를 명확히 하여 1. 전자금융거래의 안전성과 신뢰성을 확보함과
아울러 2. 전자금융업의 건전한 발전을 위한 기반조성을 함으로써 3. 국민의 금융편의를 꾀하고 4. 국민경제의
발전에 이바지함을 목적으로 한다.
제1조(목적) 이 규정은 「전자금융거래법」(이하 "법"이라 한다) 및 동법 시행령(이하 "시행령"이라 한다)에서
금융위원회에 위임한 사항과 그 시행에 필요한 사항 및 다른 법령에 따라 금융감독원의 검사를 받는 기관의
정보기술부문 안전성 확보 등을 위하여 필요한 사항을 규정함을 목적으로 한다.

8
제3장 전자금융거래의 안전성 확보 및 이용자 보호
제21조(안전성의 확보의무)
① 금융회사등은 전자금융거래가 안전하게 처리될 수 있도록 선량한 관리자로서의 주의를 다하여야 한다. <개정 2013. 5. 22., 2020. 5. 19.>
② 금융회사등은 전자금융거래의 안전성과 신뢰성을 확보할 수 있도록 전자적 전송이나 처리를 위한 인력, 시설, 전자적 장치, 소요경비 등의
정보기술부문, 전자금융업무 및 「전자서명법」에 의한 인증서의 사용 등 인증방법에 관하여 금융위원회가 정하는 기준을 준수하여야 한다. <개정 2008. 2.
29., 2013. 5. 22., 2014. 10. 15.>
③ 금융위원회는 제2항의 기준을 정할 때 특정 기술 또는 서비스의 사용을 강제하여서는 아니 되며, 보안기술과 인증기술의 공정한 경쟁이 촉진되도록
노력하여야 한다. <개정 2014. 10. 15.>
④ 대통령령으로 정하는 금융회사 및 전자금융업자는 안전한 전자금융거래를 위하여 대통령령으로 정하는 바에 따라 정보기술부문에 대한 계획을
매년 수립하여 대표자의 확인ㆍ서명을 받아 금융위원회에 제출하여야 한다. <신설 2013. 5. 22.>
1. 전자금융거래법

9
제3장 전자금융거래의 안전성 확보 및 이용자 보호
제21조(안전성의 확보의무)
① 금융회사등은 전자금융거래가 안전하게 처리될 수 있도록 선량한 관리자로서의 주의를 다하여야 한다. <개정 2013. 5. 22., 2020. 5. 19.>
② 금융회사등은 전자금융거래의 안전성과 신뢰성을 확보할 수 있도록 전자적 전송이나 처리를 위한 인력, 시설, 전자적 장치, 소요경비 등의
정보기술부문, 전자금융업무 및 「전자서명법」에 의한 인증서의 사용 등 인증방법에 관하여 금융위원회가 정하는 기준을 준수하여야 한다. <개정 2008. 2.
29., 2013. 5. 22., 2014. 10. 15.>
③ 금융위원회는 제2항의 기준을 정할 때 특정 기술 또는 서비스의 사용을 강제하여서는 아니 되며, 보안기술과 인증기술의 공정한 경쟁이 촉진되도록
노력하여야 한다. <개정 2014. 10. 15.>
④ 대통령령으로 정하는 금융회사 및 전자금융업자는 안전한 전자금융거래를 위하여 대통령령으로 정하는 바에 따라 정보기술부문에 대한 계획을
매년 수립하여 대표자의 확인ㆍ서명을 받아 금융위원회에 제출하여야 한다. <신설 2013. 5. 22.>
1. 전자금융거래법

10
제3장 전자금융거래의 안전성 확보 및 이용자 보호, 제1절 통칙
제7조(전자금융거래 종류별 안전성 기준) 법 제21조제2항의 "금융위원회가 정하는 기준"이라 함은 다음 각 호의 내용에 관하여 제8조 부터 제37조에서
정하는 기준을 말한다.
1. 인력, 조직 및 예산 부문 <개정 2013. 12. 3.>
2. 건물, 설비, 전산실 등 시설 부문
3. 단말기, 전산자료, 정보처리시스템 및 정보통신망 등 정보기술부문
4. 그 밖에 전자금융업무의 안전성 확보를 위하여 필요한 사항
제11조(전산실 등에 관한 사항) 금융회사 또는 전자금융업자는 전산실에 관하여 다음 각 호의 사항을 준수하여야 한다. <개정 2013. 12. 3.>
1. 화재ㆍ수해 등의 재해 및 외부 위해(危害) 방지대책을 수립ㆍ운용할 것
10. 다음 각 목의 중요 시설 및 지역을 보호구역으로 설정 관리할 것
가. 전산센터 및 재해복구센터
나. 전산자료 보관실
다. 정보보호시스템 설치장소
라. 그 밖에 보안관리가 필요하다고 인정되는 정보처리시스템 설치장소
11. 국내에 본점을 둔 금융회사의 전산실 및 재해복구센터는 국내에 설치할 것 <개정 2016. 6. 30.>
2. 전자금융감독규정

11
제3장 전자금융거래의 안전성 확보 및 이용자 보호, 제4절 정보기술부문
제13조(전산자료 보호대책)
① 금융회사 또는 전자금융업자는 전산자료의 유출, 파괴 등을 방지하기 위하여 다음 각 호를 포함한 전산자료 보호대책을 수립ㆍ운용하여야 한다. <개정
2013. 12. 3.>
6. 비상시에 대비하여 보조기억매체 등 전산자료에 대한 안전지출 및 긴급파기 계획을 수립ㆍ운용할 것 <개정 2013. 12. 3.>
8. 중요도에 따라 전산자료를 정기적으로 백업하여 원격 안전지역에 소산하고 백업내역을 기록ㆍ관리할 것
9. 주요 백업 전산자료에 대하여 정기적으로 검증할 것
제14조(정보처리시스템 보호대책) 금융회사 또는 전자금융업자는 정보처리시스템의 안전한 운영을 위하여 다음 각 호를 포함한 보호대책을
수립ㆍ운용하여야 한다.<개정 2013. 12. 3.>
3. 정보처리시스템의 장애발생 시 장애일시, 장애내용 및 조치사항 등을 기록한 장애상황기록부를 상세하게 작성ㆍ보관할 것
5. 시스템 통합, 전환 및 재개발 시 장애 등으로 인하여 정보처리시스템의 운영에 지장이 초래되지 않도록 통제 절차를 마련하여 준수할 것
제15조(해킹 등 방지대책)
② 제1항제1호의 규정에 따른 정보보호시스템을 설치ㆍ운영하는 경우에는 다음 각 호의 사항을 준수하여야 한다.
6. 시스템 장애, 가동중지 등 긴급사태에 대비하여 백업 및 복구 절차 등을 수립ㆍ시행할 것 <종전의 제5호에서 이동>
④ 금융회사 또는 전자금융업자는 해킹 등 전자적 침해행위로 인한 피해 발생시 즉시 대처할 수 있도록 적절한 대책을 마련하여야 한다. <개정 2013. 12. 3.>
제16조(악성코드 감염 방지대책)
① 금융회사 또는 전자금융업자는 악성코드 감염을 방지하기 위하여 다음 각 호를 포함한 대책을 수립ㆍ운용하여야 한다. <개정 2013. 12. 3.>
3. 악성코드 감염에 대비하여 복구 절차를 마련할 것
② 금융회사 또는 전자금융업자는 악성코드 감염이 발견된 경우 악성코드 확산 및 피해를 최소화하기 위하여 필요한 조치를 신속하게 취하여야 한다.

12
제23조(비상대책 등의 수립ㆍ운용)
① 금융회사 또는 전자금융업자는 장애ㆍ재해ㆍ파업ㆍ테러 등 긴급한 상황이 발생하더라도 업무가 중단되지 않도록 다음 각 호의 내용을 포함한
업무지속성 확보방안을 수립ㆍ준수하여야 한다. <개정 2013. 12. 3., 2016. 10. 5.>
1. 상황별 대응절차
2. 백업 또는 재해복구센터를 활용한 재해복구계획
3. 비상대응조직의 구성 및 운용
4. 입력대행, 수작업 등의 조건 및 절차
5. 모의훈련의 실시
6. 유관기관 및 관련업체와의 비상연락체제 구축
7. 보고 및 대외통보의 범위와 절차 등
② 제1항에 따른 업무지속성 확보대책에는 비상사태에 대비한 다음 각 호의 안전대책이 반영되어야 한다.
1. 파업 시 핵심전산업무 종사자의 근무지 이탈에 따른 정보처리시스템의 마비를 방지하기 위하여 비상지원인력을 확보ㆍ운영할 것
2. 비상사태 발생 시에도 정보처리시스템의 마비를 방지하고 신속히 원상복구가 될 수 있도록 정보처리시스템 운영에 대한 비상지원인력 또는 외부
전문업체를 활용하는 방안을 수립ㆍ운영할 것
3. 비상지원인력이 사용법을 충분히 이해하고 업무운용이 가능한 수준으로 전산시스템 운영지침서, 사용자매뉴얼 등을 쉽고 자세하게 작성하고
최신상태로 유지할 것
4. 핵심전산업무 담당자 부재 시에도 비상지원 인력이 업무를 수행할 수 있도록 비상지원인력에 대한 연수를 실시할 것

13
③ 금융회사 또는 전자금융업자는 제1항의 규정에 따른 업무지속성 확보대책의 실효성ㆍ적정성 등을 매년 1회 이상 점검하여 최신상태로 유지하고
관리하여야 한다. <개정 2013. 12. 3.>
④ 「국가위기관리기본지침」에 따라 금융위원회가 지정한 금융회사는 금융위원회의 「금융전산분야위기대응실무매뉴얼」에 따라 위기대응행동매뉴얼(이하
"행동매뉴얼"이라 한다)을 수립ㆍ준수하고 이를 금융위원회에 알려야 한다. <개정 2013. 12. 3., 2016. 10. 5.>
⑤ 금융위원회가 별도로 지정하지 아니한 금융회사 또는 전자금융업자는 자연 재해, 인적 재해, 기술적 재해, 전자적 침해 등으로 인한 전산시스템의 마비
방지와 신속한 복구를 위한 비상대책을 수립ㆍ운영하여야 한다. <개정 2013. 12. 3., 2016. 10. 5.>
⑥ 제4항에 따른 행동매뉴얼 또는 제5항에 따른 비상대책에는 제1항의 규정에 따른 업무지속성 확보대책이 반영되어야 한다.
⑦ 금융회사 또는 전자금융업자는 중앙처리장치, 데이터저장장치 등 주요 전산장비에 대하여 이중화 또는 예비장치를 확보하여야 한다. <개정 2013. 12. 3.>

14
⑧ 다음 각 호의 금융회사는 시스템 오류, 자연재해 등으로 인한 전산센터 마비에 대비하여 업무지속성을 확보할 수 있도록 적정 규모ㆍ인력을 구비한
재해복구센터를 주전산센터와 일정거리 이상 떨어진 안전한 장소에 구축ㆍ운용하여야 한다. <개정 2013. 12. 3., 2015. 6. 24.>
1. 「은행법」에 의해 인가를 받아 설립된 은행(다만,「은행법」제58조에 의해 인가를 받은 외국금융회사의 국내지점은 제외한다) <개정 2013. 12. 3.>
2. 「한국산업은행법」에 의한 한국산업은행, 「중소기업은행법」에 의한 중소기업은행, 「농업협동조합법」에 의한 농협은행, 「수산업협동조합법」에 의한
수산업협동조합중앙회의 신용사업부문 <개정 2013. 12. 3.>
3. 「자본시장과 금융투자업에 관한 법률」에 의한 투자매매업자ㆍ투자중개업자(다만, 「자본시장과 금융투자업에 관한 법률」 제12조에 의해 인가를 받은
외국 투자매매업자ㆍ투자중개업자의 지점 등은 제외한다)
4. 「자본시장과 금융투자업에 관한 법률」에 의한 증권금융회사 및 한국예탁결제원
5. 「자본시장과 금융투자업에 관한 법률」에 의한 거래소 <개정 2013. 12. 3.>
6. 「여신전문금융업법」에 의한 신용카드업자(다만, 법인신용카드 회원에 한하여 신용카드업을 영위하는 자는 제외한다)
7. 「보험업법」에 의한 보험요율산출기관
8. 「상호저축은행법」에 의한 상호저축은행중앙회
9. 「신용협동조합법」에 의한 신용협동조합중앙회
10. 「보험업법」에 의한 보험회사
⑨ 제8항 각 호의 금융회사는 업무별로 업무지속성 확보의 중요도를 분석하여 핵심업무를 선정하여야 하며, 업무별 복구목표시간을 정하여야 한다. 이 경우
핵심업무의 복구목표시간은 3시간 이내로 하되, 「보험업법」에 의한 보험회사의 핵심업무의 경우에는 24시간 이내로 한다. <신설 2015. 6. 24.>
⑩ 제8항의 규정에 따른 재해복구센터를 운영하는 금융회사는 매년 1회 이상 재해복구센터로 실제 전환하는 재해복구전환훈련을 실시하여야 한다. ,
<종전의 제9항에서 이동 2015. 6. 24.> <개정 2013. 12. 3.>

15
제3장 전자금융거래의 안전성 확보 및 이용자 보호, 제4절 정보기술부문 – 클라우드 이용 관련
제14조의2(클라우드컴퓨팅서비스 이용절차 등)
① 금융회사 또는 전자금융업자는 「클라우드컴퓨팅 발전 및 이용자 보호에 관한 법률」 제2조제3호에 따른 클라우드컴퓨팅서비스를 이용하고자 하는 경우
다음 각 호의 절차를 수행하여야 한다. <개정 2018. 12. 21.>
3. 클라우드컴퓨팅서비스 이용과 관련한 업무 연속성 계획 및 안전성 확보조치의 수립ㆍ시행(단, 제1호의 평가를 통해 비중요업무로 분류된 업무에
대해서는 <별표 2의3> 및 <별표 2의4>의 필수 사항만 수립ㆍ시행할 수 있다.) <개정 2022. 11. 23.>
② 금융회사 또는 전자금융업자는 제1항 각 호에 따른 평가결과, 업무연속성 계획 및 안전성 확보조치에 대하여 제8조의2에 따른 정보보호위원회의
심의ㆍ의결을 거쳐야 한다. <개정 2018. 12. 21., 2022. 11. 23.>
④ 금융회사 또는 전자금융업자는 다음 각 호의 어느 하나에 해당하는 사유가 발생한 날로부터 3개월 이내에 발생 사유, 관련 자료 및 대응계획을 첨부하여
금융감독원장에게 보고하여야 한다.<신설 2018. 12. 21., 개정 2022. 11. 23.>
⑥ 클라우드컴퓨팅서비스를 이용하는 금융회사 또는 전자금융업자는 제4항에 따른 보고의무와 관계없이 제5항 각호에 따른 서류를 최신상태로 유지하여야
하며, 금융감독원장의 요청이 있을 경우 이를 지체 없이 제공하여야 한다.<신설 2018. 12. 21., 개정 2022. 11. 23.>

16
중요 업무 비중요 업무
데이터백업 등 장애 대비 (필수)
클라우드서비스와 관련된 중요 설정파일, 가상 시스템 등 데이터
백업에 포함 (추가)
이중화 또는 예비장치 확보 등 (필수)
동시 장애 발생 가능성 등을 고려하여 중복 설계 및 구성 (추가)
훈련 및 사고 관리 (필수)
훈련 및 사고관리 계획에 클라우드서비스 제공자의 역할, 책임,
비상연락망 등이 포함되도록 고려 (추가)
비상대책수립 (필수)
계약 변경, 파산 등 대비한 공급 대체 방안, 업무 복구 가능성 식별 등
출구 전략 수립 고려 (추가)
2. 전자금융감독규정 - [별표 2의3] 업무연속성계획

금융 IT DR 규제 Compliance
17
업무연속성 확보 AWS
클라우드서비스와 관련된 중요 설정파일, 가상 시스템 등 데이터 백업에 포함
(추가)
AWS 기반에서 업무연속성 확보 방안
수립하고 이행하여 IT DR 규제요건을
준수하고 있습니다.
동시 장애 발생 가능성 등을 고려하여 중복 설계 및 구성 (추가)
훈련 및 사고관리 계획에 클라우드서비스 제공자의 역할, 책임, 비상연락망
등이 포함되도록 고려 (추가)
계약 변경, 파산 등 대비한 공급 대체 방안, 업무 복구 가능성 식별 등 출구 전략
수립 고려 (추가)

DR Overview
18

Disaster Recovery와 기업 가치
19
Disaster Recovery의 실패는
기업가치의 하락으로 이어짐

911테러와 금융 DR
20
금융사들의 대응
연방준비이사회(Federal Reserve Board) 권고 사항
2002년2월 연방준비이사회는 대형 금융 기관과
협의하여 다음과 같은 권고 사항을 정의함.
•DR 및 업무연속성 계획은 대규모 및 지역적 장애를
포함해서 구성해야 함.
•업무연속성 계획은 핵심 업무에 RPO를 적용해야함.
(이전까지는 보관기간에 초점이 있었음)
•DR 계획에 대해서 테스트를 정례화 할 것.
•많은 중소 금융사들은 데이터 유실이 발생함.
•Merrill Lynch는 9/11에 두 개의 데이터 센터를 잃었음.
=> 이후 주요 핵심서비스들에 대해서 여러센터에
분산하여 구성함.
•Morgan Stanley는 또한 9/11 이전에 서로 가까이
있던 데이터 센터를 9/11 이후에 분리함.

DR 구성 계획
21

DR구현의 방해 요소
22
• 지속적인 관리에 대한 투자 부족
- 재해 복구의 주요 장애물 중 하나는 지속적인 최고 경영진의 노력이 부족이 있음
- 최고 경영진은 특히 비즈니스 및 경쟁 압력의 영향을 받는 시기에 DR 또는 BCP 사이트의 설립을 승인할 수 있으나 사이트를 항상
완벽하게 운영하는 데 필요한 지속적인 예산과 인력을 기꺼이 투자하지 않으려는 경향들이 있음.
• 부적절한 예산
- 비즈니스 관리자가 DR 및 BC 옵션을 설정하는 데 충분히 투자할 수 없거나 투자할 의사가 없는 경우가 있음.
- 재해 복구 옵션에는 중복 장비, 예비 부품, 데이터 동기화 장비, 소프트웨어, 하드웨어, 교육, 보험, 대체 사이트 등에 대한 투자가
필요한데, 이 부분에 대한 투자가 적절하지 못함.
• 인력
- DR 사이트를 유지 관리하는 데 필요한 추가 기술 인력에 투자할 의향이 없음.
• 지식
- 적절한 재해 복구를 설정하는 데 필요한 지식이 부족.
• 기타 이유
- 다양한 내부 요인 및 제한 사항.

DR 준비의 딜레마: 준비를 잘 할수록 비용 증가
23
• 복구 시간 단축 => 비용 증가
- 재난 발생 후 데이터를 더 빨리 사용할 수 있기를 원할수록 더 많은 비용이 듭니다.
• 이격 거리 증가 => 비용 증가
- 신속하게 복구해야 하는 데이터를 더 멀리 저장할수록 비용이 더 많이 듭니다. 주로 이 비용은 두 개 이상의 시설 사이의 전용 고속
WAN 연결과 관련됩니다.
• 복구하려는 데이터량 증가 => 비용 증가
- 재해 직후에 제공하려는 데이터가 많을수록 더 많은 비용이 듭니다. 이 비용은 필요한 저장소 중복성을 달성하기 위해 구입해야
하는 저장소의 양과 관련이 있습니다.
• 데이터 특성에 따른 세밀한 복구 계획 => 비용 증가
- 여러 솔루션을 포함하는 다양한 방식의 데이터 보호 및 복구 계획은 단순한 계획보다 비용이 많이 듭니다. 예를 들어, 데이터의
일부에 대한 미러링, 데이터의 다른 부분에 대한 레플리케이션, 나머지 데이터에 대한 테이프 백업 복구 등의 형태로 세분화된 복구
계획이 있을 경우가 비용이 더 발생합니다. 단순한 데이터 복구 계획은 세밀하고 복잡한 계획보다 비용 효율적입니다.

Goldilocks zone
24
N O T T O O C L O S E , A N D N O T T O O F A R , B U T J U S T R I G H T
Distance between data centres
10s of microseconds 100s of microseconds Milliseconds
0
microseconds
Goldilocks zone
Across the street Kilometers 10s of kilometers 100s of kilometers
Corporate data
centre

DR 프로젝트의 시작: BIA (Business Impact Analysis)
25
비즈니스 영향 분석 수행
• DR 프로젝트의 첫 번째 주요 작업은 DR 계획이
필요한 비즈니스 기능(function) 식별하는
것입니다.
• 각 중요한 비즈니스 기능에 대한 위험 분석을
수행하여 장애가 발생하는 상황에 대해서
비즈니스에 미치는 영향을 정량화해야 합니다.
BIA
Lifecycle
Structure
BIA
Identify
Stakeholders
Book
Meeting
BIA
Interview
Analyze
Response
Review
Meeting
Approve
BIA
Final
Analysis
Final
BIA

BIA의 주요 의사결정 항목
26
Maximum Tolerable Downtime RTO / RPO
• 회사의 중요한 프로세스에 대해서 비즈니스의 생존 자체를
위협하기 전에 복구해야 하는 시간 중에 가장 긴 시간 이 수치를
최대 허용 다운타임(MTD)이라고 합니다.
• MTD를 몇 시간 또는 며칠 단위로 측정할 수 있습니다.
• 각 중요 프로세스에 대해 MTD를 설정하는 것은 다소
임의적입니다. DR계획을 위해서는 각 프로세스에 대해
의사결정에 필요한 몇 가지 수치를 설정해야 합니다. 나중에
분석 결과 수치가 너무 높거나 낮으면 언제든지 수치를 조정할
수 있습니다.
• 복구 시간 목표(RTO): 비즈니스 프로세스를 다시 시작하기 전에 사용할 수
없는 최대 시간입니다. 예를 들어 RTO를 24시간으로 설정합니다. 오후
3시에 재해가 발생하여 비즈니스 프로세스가 중단됩니다. RTO가
24시간이라는 것은 비즈니스 프로세스를 다음날 오후 3시까지 다시
시작한다는 의미입니다.
• RTO는 MTD보다 작아야 합니다. 예를 들어 주어진 프로세스에 대해
MTD를 2일로 설정한 경우 RTO를 2일 미만으로 설정해야 합니다. 그렇지
않으면 프로세스를 다시 실행하기 전에 비즈니스가 실패할 수
있습니다(또는 실패할 수 있습니다). 즉, 특정 비즈니스 프로세스를 이틀
동안 사용할 수 없으면 비즈니스가 실패할 것이라고 생각하는 경우 해당
프로세스를 복구하려는 목표 시간을 2일보다 훨씬 짧게 설정해야 합니다.
• RPO(복구 지점 목표): 재해로 인해 중요한 비즈니스 프로세스가 중단되는
경우 조직에서 허용할 수 있는 최대 데이터 손실량입니다. 예를 들어
프로세스의 RPO를 1시간으로 설정했다고 가정합니다. 비즈니스
프로세스를 다시 시작하면 사용자는 1시간 이상의 작업을 잃지 않습니다.

Maximum Tolerable Downtime(MTD) vs. RTO
27

Recovery 전략
28
2계층 복구 전략 (Two-tier recovery)
1계층 복구 전략 (One-tier recovery)
• 고가의 데이터 복제를 사용하여 조직의 모든 데이터를 보호하고 복구할 수 있습니다.
• 이 접근 방식은 모든 데이터를 보호하기 위한 초기 비용이 더 많이 들지만 이 전략은 "2계층
복구 전략"보다 더 간단하고 구현하기 쉽습니다.
• 이 접근 방식은 단순성이 추가 비용보다 중요하다고 판단될 때 사용됩니다.
• 일반적으로 이 접근 방식은 더 쉽고 안정적으로 복구할 수 있습니다.
• 고가의 데이터 복제 메커니즘에 대해서는 복구시간이 가장 중요한 데이터만 보호합니다.
• 복구 시간에 덜 민감한 나머지 데이터를 백업 테이프와 같은 저렴한 매체를 이용하여
복구합니다.
• 모든 데이터에 대해서 고가의 복제 기술을 사용하는 것보다 비용이 저렴한 방식을 선호할
때 이 전략으로 구성합니다.

DR 테스트
29

DR 테스트 종류
30
Test Explanation
Checklist (paper
test)
DR을 책임지는 직원들은 각자의 체크리스트에 대해서 DR계획의 정확성과 완전성을 개별적으로 검토합니
다.
Walkthrough DR을 책임지는 직원들은 함께 모여 DR 계획을 그룹으로 진행하면서 각 단계를 논의합니다.
Simulation
해당 지역에서 발생하는 재해 이벤트들을 감안해서 가상 재해 상황을 가정한 다음, 직원들은 주기적인 재해
선포를 시작으로 실제 재난 복구 시뮬레이션을 수행합니다. 하지만 해당 훈련 방식은 가상 훈련 방식이기
때문에 복구팀은 실제로 복구 단계를 수행하지 않습니다.
Parallel
이 테스트는 기본 일상 비즈니스 프로세스는 중단 없이 계속되는 상황에서 복구환경을 추가적으로
구성해서 재난복구를 병행하는 방식입니다. 재난복구팀은 실제 복구 단계를 수행하여 비즈니스 프로세스를
대체 위치로 이동합니다. 재난복구팀은 복구 서버를 구축하거나 시작하고 복구 서버를 통해 일부 실제 비즈
니스 트랜잭션을 실행합니다.
Interruption
(cutover test)
비즈니스는 실제 재해가 발생한 것처럼 중요한 비즈니스 프로세스 수행을 중단합니다. 복구팀과 연관 직원
들은 interim DR 계획에 따라 업무를 수행합니다.(서버 업그레이드 등의 작업에서도 주로 사용)

DR Test vs. Cost & Complexity
31
소요 리소스량(인력, 자원)
구성
복잡도
Paper
Test
Workthrough
Test
Parallel
Test
Cutover
Test
복합 콤포넌트
테스트
개별 콤포넌트
테스트
Simulation
Test

금융사 DR 훈련 방식(Parallel testing)의 특징
32
• Do no harm to infrastructure
- 이 테스트에서는 기존 네트워크, 시스템, 데이터베이스 및 애플리케이션에 영향을 주지 않도록 합니다.. 기존 시스템은 여전히 실제 비즈니스를 수행하고 계속되어야
하는 기존 비즈니스 프로세스를 지원합니다.
• Do no harm to staff
- 이 테스트에는 정규 업무를 수행하는 직원외에 추가 직원이 작업할 수 있도록 합니다. 복구 테스트 요원은 실제 운영 직원을 방해해서는 안 됩니다.
• Acquiring replacement equipment.
- 일부 DR 계획에서는 조직에서 이미 소유하고 있는 시스템을 복구 시스템으로 사용합니다. 다른 경우에는 조직에서 복구 시스템을 구입해야 합니다. 병렬 테스트를
추가적인 구매가 실제로 발생하지 않도록 계획을 어느 정도 변경해야 할 수도 있습니다.
• Side-by-side transactions
- 병렬 테스트 중인 비즈니스 프로세스 및 IT 시스템의 특성에 따라 실제 시스템과 병렬 테스트 시스템을 통해 실제 비즈니스 트랜잭션의 일부 또는 전체를 실행할 수
있습니다. DR 프로젝트 팀은 DR 시스템에서 실행할 트랜잭션을 결정할 때 사용할 기준을 결정해야 합니다.
• Actual load or simulated load
- 비즈니스 특성상 테스트의 유효성을 검사하기 위해 트랜잭션의 작은 부분만 수행해야 할 수도 있습니다. 그러나 테스트가 유효하려면 복구 시스템을 통해 더미
데이터만 실행하더라도 복구 시스템이 전체 워크로드를 처리해야 할 수 있습니다. 테스트에는 시스템의 올바른 작동을 검증하기 위해 두 가지 유형의 테스트(소수의 실제
트랜잭션과 전체 워크로드 테스트)가 필요할 수도 있습니다.
• External interfaces
- 가능한 한 모방하는 실제 프로덕션 시스템과 유사하게 병렬 테스트를 만드십시오. 그러나 바람직하지 않은 특정 이벤트를 피할 수 있도록 테스트의 일부를
시뮬레이션해야 합니다. 예를 들어, 애플리케이션이 결제를 위해 거래를 은행이나 결제 프로세서로 보내는 경우 테스트 시스템도 해당 거래를 전송하지 않도록 해야
합니다. 그렇지 않으면 조직에서 결제 횟수와 금액이 두 배로 발생합니다. 이 원칙을 다른 내부 애플리케이션에 적용해야 할 수도 있습니다.
• Make the test as real as possible
- 이 목록에서 언급한 모든 제한 사항에도 불구하고 병렬 테스트의 요점은 DR 계획이 재해 중에 작동하는지 확인하는 것입니다. 결과적으로 DR 테스트 담당자가 어려운
문제를 파악하도록 내버려 두십시오. 절차가 완벽하지 않을 수 있으므로 테스트 담당자를 어느 정도 제한해야 합니다. 어떻게든 실제 재해가 발생했을 때보다 더 쉽게
장애물을 극복하여 속일 수 없도록 해야 합니다.

DR to Resiliency
33

DR에 사용할 수 있는 기술
34
Server Load Balancing
Database Replication
Disk Mirror

DR 아키텍처의 종류
35
Cold Recovery Warm Recovery Hot Standby Resilient Architecture
Cost/Complexity Low/Simple Medium/Moderate High/Complex
Very High/
Very Complex
Recovery Time
(RTO)
24 Hours 4 – 24 Hours 0 – 4 Hours 0
Data Loss
(RPO)
Last Backup
Last Backup/
Mirror
0 - Seconds 0
Related
Technology
•준비되었거나 실행할 준비가 된
하드웨어나 소프트웨어가 없음.
•하드웨어가 할당됨. 데이터 센터 바닥에
있으며 전원 및 네트워크 연결이 필요함.
•하드웨어를 구성해야 함. 운영 체제와
응용 프로그램은 종종 구축되지만
로드되지 않을 수 있음.
•애플리케이션 데이터도 콜드 복구
구성에 스토리지에 저장해서 복구시
사용해야 함.
•일반적으로 오프라인형태로 복제된
하드웨어로 준비.
•사용할 준비가 된 소프트웨어. 이는
프로덕션 환경의 일부로 변경시
제어되어야 함(변경관리필요).
일반적으로 이벤트(장애) 사이에는
소프트웨어가 실행되지 않음.
•미러링된 데이터, 데이터볼트 또는
테이프 기반 데이터(VTL, PTL).
•복제된 데이터
•복제된 하드웨어
•복제된 소프트웨어
•준비 상태에서 실행
•라이브/패시브
•미러링된 데이터
•신속/자동 장애 복구
•논스톱 fault tolerant
•라이브/라이브, 지리적으로
분산

Resilient Architecture
36
Router
Firewall
Load
Balancer
Server
Database
Router
Router
Firewall
Load
Balancer
Server
Database
Router
Primary Center Secondary Center
Active Active

Thank you!

[금융고객을 위한 Resiliency in the Cloud] 최근 대규모 장애 사태 여파에 따른 DR 동향과 최신 관련 규제 업데이트

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à [금융고객을 위한 Resiliency in the Cloud] 최근 대규모 장애 사태 여파에 따른 DR 동향과 최신 관련 규제 업데이트

Similaire à [금융고객을 위한 Resiliency in the Cloud] 최근 대규모 장애 사태 여파에 따른 DR 동향과 최신 관련 규제 업데이트 (20)

Plus de AWS Korea 금융산업팀

Plus de AWS Korea 금융산업팀 (20)

[금융고객을 위한 Resiliency in the Cloud] 최근 대규모 장애 사태 여파에 따른 DR 동향과 최신 관련 규제 업데이트