블로그

재해 복구 계획에 포함해야 할 13 가지 사항

재해 복구 계획 (DRP) is a document you need to keep handy to handle unexpected incidents that could shut down your company’s IT systems and hinder its overall operation.
A DRP aims to get your business up and running as quickly as possible during a disaster or data breach. With an 효과적인 재해 복구 계획, 너무 오랫동안 이익을 잃을 가능성이 적습니다. 또한 민감한 데이터 (사회 보장 번호 또는 신용 카드 정보)가 손상되지 않도록 백업을 설정해야합니다.

귀사에 재해 복구 계획이 있습니까?

데이터 손실, 다운 타임 및 기술 분노는 오늘날 최고의 회사조차도 접하는 새로운 공포 이야기 중 일부입니다. 회사에 재난이 발생할 때마다 엔지니어링 팀은 손상을 복구하기 위해 서두르고 반면에 PR 팀은 고객의 신뢰를 회복하기 위해 초과 근무를합니다. 시간과 비용이 많이 드는 작업이라고 생각하지 않습니까? 당연하지! 그러나 일부 조직은 이러한 재난을 가장 효과적으로 관리하고 부수적 피해를 줄입니다. 방법이 궁금하세요? 간단하고 포괄적이고 따르기 쉬우 며 정기적으로 테스트되는 재해 복구 계획을 가지고 있습니다.

Disasters come uninvited with loads of complex challenges, which organizations might take months or years to overcome. Cyber attacks, tornadoes, terrorist attacks, hurricanes, and floods are some of the disasters that can cause data breaches. A disaster plan is a long-term assurance of business operability as it is designed in such a way that it enables businesses to reduce damages of unpredicted outages.

재해 복구 계획이 있거나 조직을위한 계획을 만드는 과정을 막 시작하고 있습니까? 이러한 경우 아래의 재해 복구 계획 체크리스트는 계획에 모든 중요한 구성 요소를 추가하는 데 도움이됩니다.

1. 잠재적 위협 및 가능한 대응 분석

첫 번째는 시간을내어 비즈니스 흐름을 방해 할 수있는 모든 가능한 요소를 분석하는 것입니다. 연구를 마쳤 으면 각 시나리오에 대해 다른 복구 계획을 만들어야합니다. 예를 들어, 사이버 공격이 더욱 널리 퍼지고 발생할 가능성이 높아지고 있으며, 안타깝게도 평균 방화벽은 대부분의 공격으로부터 보호 할만큼 강력하지 않습니다.

따라서 쓰나미보다 사이버 공격의 가능성을 더 자세히 살펴보십시오. 데이터 암호화 및 하드웨어 보안을 선택할 수 있습니다. 해커가 액세스 권한을 얻기 위해 사용하는 진입 점이므로 시스템 내에있는 취약점을 이해하십시오.

가장 좋은 방법은 해커가 사용하는 많은 계획에 대해 최신 정보를 유지하는 것입니다. 대부분의 피싱 및 맬웨어 감염을 피할 수 있습니다.

2. 재해 복구 목표 수정

재해 복구는 비즈니스를 평소와 같이 지속적으로 운영하는 데 도움이되므로 조직을 운영하는 데 가장 중요한 IT 서비스를 수정해야합니다. 또한 이러한 서비스 / 머신에 필요한 복구 시간 목표 (RTO) 및 복구 지점 목표 (RPO). 하지만 RTO와 RPO를 알고 계십니까?

RPO : 비즈니스 중단 알림 후 재해에서 복구하는 데 필요한 시간입니다. 재난 발생시 경쟁 업체에 고객을 잃지 않고 최소 1 시간의 다운 타임을 견딜 수 없다면 매우 중요합니다. 명확하게 표시된 허용 RTO로 구성된 안정적인 재해 복구 계획이 필요합니다.

RPO : 데이터가 허용되는 기간입니다. 재해 발생 후 하루 종일 업무를 수행 한 후 4 시간 동안 만 데이터 손실을 견뎌 낼 수 있다면 중요한 데이터가 치명적인 손실을 입을 수 있으므로 RPO는 4 시간이됩니다.

조직의 RTO 및 RPO는 복구 전략 및 관련 비용에 영향을 미칠 것입니다. 재해 복구 전략의 총 비용을 줄이려면 응용 프로그램을 계층으로 나누는 것이 좋습니다. 미션 크리티컬 애플리케이션 용으로 예약 된 최상위 계층에는 실시간 연속 데이터 복제를 기반으로하는 재해 복구 기술이 필요합니다. 중간 수준의 계층에는 스냅 샷 기반 응용 프로그램이 필요할 수 있으며 마지막으로 가장 낮은 계층은 간단한 파일 수준 백업 시스템을 사용할 수 있습니다.

3. 재해 복구 계획의 이해 관계자를 인식합니다.

다음으로 중요한 단계는 재난이 발생하면 업데이트해야하는 사람들을 식별하는 것입니다. 엔지니어, 지원, 임원 등이 실제 재해 복구를 수행하는 데 관여합니다. 그래도 공급 업체, PR 및 마케팅 팀 구성원, 타사 공급 업체 및 주요 고객과 같은 다른 사람도 식별해야합니다. 대부분의 회사는 재해 발생시이를 알리기 위해 프로젝트 사무실 문서에 이해 관계자의 등록을 유지합니다.

4. 재해 복구 사이트 만들기

재해로 인해 프로덕션 센터가 심각하게 손상 될 가능성이 높으므로 기본 사이트에서 작업을 재개 할 수 없으므로 중요한 워크로드를 다른 위치로 마이그레이션 할 수 없습니다. 재해 복구 계획에 따르면 중요 데이터, 직원, 물리적 리소스, 광고 애플리케이션의 긴급 재배치시 사용할 DR 사이트를 구축하는 데 필요한 체크리스트입니다. 또한 사이트에 필수 워크로드를 처리하기에 충분한 하드웨어와 소프트웨어를 갖추어야합니다.

5. 전체 인프라 문서 수집

재난이 발생하면 모든 것이 무너지고 모든 사람이 압력을받습니다. 실제로 재해 복구 절차를 활성화하는 데 필요한 기술과 지식을 갖춘 엔지니어링 팀이 있지만 인프라 문서는 필수입니다. 재해 복구를 수행하는 동안 능숙한 엔지니어조차도 인프라 문서에서 명령을 실행하는 것을 선호합니다.

그렇다면이 문서는 무엇으로 구성되어 있습니까? 전체 시스템 설정 및 사용 (설치, 복구 절차, 실행중인 애플리케이션, OS 및 구성), 클라우드 템플릿, 저장소 및 데이터베이스 (데이터 저장 방법 및 위치, 백업 복원 방법, 데이터 정확성 확인 방법) 모든 매핑 된 네트워크 연결 (작동하는 장치 및 해당 구성 포함).

6. 정확한 기술 선택

Disaster Recovery as a Service (DRaaS) and on-premise disaster recovery is not just the feasible solutions available for business continuity. The next option is to make use of cloud-based disaster recovery in order to spin up your disaster recovery site on a public cloud-like 마이크로 소프트 애저AWS 과 구글 클라우드 in minutes using an automated disaster recovery solution.

솔루션을 선택하기 전에 총 소유 비용, 유지 관리 요구 사항, 확장 성, 이전 시점으로의 복구 및 테스트 용이성을 고려하십시오. 재해 복구 솔루션과 관련하여 선택 사항이 많으므로 철저한 조사를 수행하고 현명하게 선택하십시오.

7. 통신 채널 시작

재해가 언제 문을 두드 릴지 아무도 모르기 때문에 조직으로서 재해 복구를 위해 팀 목록 (역할 및 연락처 정보 포함)을 유지해야합니다. 각 엔지니어링 팀 (예 : 데이터베이스, 시스템, 네트워크, 스토리지) 및 관련 경영진의 책임있는 개인을 포함하는 포괄적 인 명령 체인을 구축하십시오. 또한 인스턴트 메시징에 사용할 전용 통신 채널 및 허브 또는 온라인 정보 공유 도구를 설정하십시오.

8. 사고 대응 절차 개요

재해 복구 계획이있는 경우 "사고 대응 절차"가 필수입니다. 여기에서 회사는 재난으로 선언해야하는 이벤트를 자세히 정의합니다. 예를 들어, 시스템이 다운되면 재앙으로 간주 하시겠습니까? 또한 계획에는 재난을 확인하는 방법과 재난이보고되는 방법 (자동 모니터링 시스템, 사이트 안정성 엔지니어링 (SRE) 팀의 요청 또는 고객보고)이 표시되어야합니다.

재해가 실제로 발생하는지 확인하려면 사전에 모니터링하는 중요한 네트워크 장치, 애플리케이션 로그, 서버 하드웨어 또는 프로덕션 시스템의 기타 중요한 구성 요소의 상태를 확인해야합니다. 뭔가 이상하거나 작동하지 않는다면, 당신의 손에 재앙이 있다는 것은 확실합니다.

9. 조치 대응 절차 개요

재해가 발생하면 가능한 한 빨리 재해 복구 환경을 활성화해야합니다. 조치 대응 절차는 필요한 모든 단계를 통해 재해 복구 사이트로 장애 조치하는 방법을 설명합니다. 복구 프로세스에서 DRaaS를 사용하든 재해 복구 도구를 사용하여 재해 사이트를 자동으로 시작하든 관계없이 필요한 서비스를 시작, 확인 및 제어하는 방법을 확인하려면 조치 대응 절차를 서면으로 준비해야합니다.

또한 다른 위치에서 생산 서비스를 가동하는 것만으로는 충분하지 않으므로 필요한 모든 데이터가 제자리에 있고 필요한 모든 비즈니스 응용 프로그램이 제대로 작동하는지 확인하는 것도 똑같이 중요합니다.

10. 기본 인프라로의 페일 백 준비

페일 백은 페일 오버 중에 DR 사이트로 전송 된 작업을 기본 프로덕션 센터에서 복원하는 것입니다. DR 사이트는 일상적인 작업을 실행하도록 설계되지 않았습니다. 대신 비상용으로 만 사용할 수 있습니다. DR 사이트는 매우 짧은 기간 동안 구축됩니다 (기본 사이트가 복원 될 때까지 또는 새 프로덕션 센터가 구축 될 때까지).

재해가 끝나면 데이터 및 비즈니스 서비스를 기본 위치로 다시 이동하는 데 많은 노력이 필요합니다. 되돌리기 프로세스 중에 비즈니스가 부분적으로 중단 될 수있는 계획을 세우십시오. 다행히도 기본 IT 위치 확인을 완료하면 자동 또는 수동으로 활성화되는 기본 위치에 대한 통합 장애 복구를 제공하는 재해 복구 솔루션이 있습니다.

11. 이해 관계자에게 사건보고

재해가 발생하면 먼저 DR 활동을 담당하는 사람뿐만 아니라 공급 업체, 고객, PR 및 마케팅 팀 구성원, 타사 공급 업체와 같은 주요 이해 관계자에게도 알립니다. 또한 각 그룹에 알리고 우려 사항을 해결하기위한 답변을 공식화하는 것을 고려하십시오. 실제 재난이 발생했을 때 시간을 낭비하지 않고 출판 할 수 있도록 미리 보도 자료를 작성하는 것이 좋습니다.

12. 광범위한 테스트 수행

재해 복구 계획 테스트는 필수이지만 일반적으로 무시됩니다. 장애 조치 테스트는 일반적으로 복잡하며 데이터 손실 및 제품 서비스 중단으로 이어집니다. 따라서 대부분의 회사는 정기적으로 재해 복구 계획을 테스트하지 않습니다.

재해 복구 계획이 얼마나 잘 작동하는지 이해하려면 정기적 인 장애 조치 테스트를 예약해야합니다. 재해 복구 계획 테스트를 무시하면 재해가 발생하는 동안 전체 비즈니스가 위험에 처할 수 있으며, 결국 제때에 복구 할 수 없거나 전혀 복구 할 수 없게됩니다. 성능 테스트는 또한 보조 위치가 비즈니스 부하를 견딜 수 있는지 여부를 평가하는 데 도움이됩니다.

13. 재해 복구 계획을 최신 상태로 유지

마지막으로 재난 복구 계획 테스트는 필수이므로 모든 재난 복구 문서를 최신 상태로 유지해야합니다. 각 테스트가 끝날 때 무슨 일이 있었는지, 팀이 테스트를 어떻게 처리하는지 검토하고 결과를 문서화합니다.

사인 오프 :

직접 재해 복구 (저렴하지만 오류가 발생하기 쉬운 옵션)를 수행하거나 회사에서 손실 된 모든 데이터를 복구하고 조직이 정상적인 비즈니스 운영으로 복귀하는 데 도움이되는 유용한 재해 복구 계획을 마련 할 수 있습니다. 또한 재난으로 인해 불리한 재정적 결과와 주요 비즈니스 중단이 발생하지 않도록 보장합니다.

조직의 모든 측면 (예 : 직원 수, 사용 가능한 예산, 위험 요소, IT 인프라 크기 등)을 고려하여 귀하와 귀하의 팀에 가장 적합한 것이 무엇인지 결정하십시오.

답장을 남겨주세요

ko_KRKorean