재해 복구(DR)는 심각한 역효과를 초래할 수 있는 이벤트의 부정적인 영향으로부터 기업을 보호하기 위한 보안 계획 영역입니다. 기업은 DR을 통해 비즈니스 운영 또는 매출 측면의 심각한 손실 없이 데이터 재해 발생 후 미션 크리티컬 기능을 그대로 유지하거나 신속하게 재개할 수 있습니다.
재해는 다양한 형태와 규모로 발생할 수 있습니다. 여기에는 지진이나 토네이도, 허리케인 같은 재해뿐만 아니라 장비 고장, 사이버 공격, 테러 등의 보안 관련 사고도 포함됩니다.
기업은 대비 과정에서 미션 크리티컬 기능을 다시 시작하기 위해 따라야 할 프로세스와 조치를 포함한 DR 계획을 수립합니다.
재해 복구는 기업의 중요 비즈니스 기능을 지원하는 IT 시스템에 중점을 둡니다. 종종 비즈니스 연속성이라는 용어와 연관되지만 이 둘의 의미가 완전히 동일하지는 않습니다. DR은 비즈니스 연속성의 일환입니다. 재해가 발생해도 모든 비즈니스 부문이 문제없이 실행되도록 유지하는 데 집중합니다.
비즈니스 성공에서 IT 시스템의 중요성이 커짐에 따라, 재해 복구가 비즈니스 연속성이라는 프로세스에서 중요한 요소로 자리잡게 되었습니다.
대부분의 비즈니스 소유자는 실제로 예기치 않은 위기가 발생할 때까지 본인이 자연 재해의 피해자가 되리라는 생각을 하지 못합니다. 결국 운영 및 경제적 손실로 회사에 엄청난 비용이 발생하는 결과를 맞게 됩니다. 이러한 사고는 예측할 수 없으므로 비즈니스 소유자는 재해 대비 계획을 제대로 마련해야 할 것입니다.
비즈니스 재해는 기술적 재해, 인적 재해 또는 자연 재해일 수 있습니다. 자연 재해의 예로는 홍수, 토네이도, 허리케인, 산사태, 지진, 쓰나미 등이 있습니다. 인적 및 기술적 재해에는 유해 물질 유출, 전력 또는 인프라스트럭처 장애, 화학 및 생물학적 무기 위협, 원자력 발전소 폭발 또는 붕괴, 사이버 공격, 테러 행위, 폭발, 시민 소요 등이 포함됩니다.
계획 시 고려해야 할 잠재적 재해는 아래와 같습니다.
규모나 산업에 관계없이 예기치 않은 상황이 발생하면 일상 업무가 중단되므로 기업은 고객 및 클라이언트에게 계속 서비스를 제공할 있도록 빠르게 복구를 수행해야 합니다.
다운타임은 비즈니스가 직면하는 가장 큰 IT 비용에 해당할 것입니다. Infrascale의 2014-2015 재해 복구 통계에 따르면, 다운타임 1시간을 기준으로 소기업에서는 8,000달러, 중견기업은 74,000달러, 대기업은 700,000달러의 비용이 발생합니다.
중소기업의 경우 생산성 하락이 계속되면서 주문 취소, 인보이스 발행 지연, 배송 날짜 누락, 다운타임 복구 노력에 따른 추가 근무 시간으로 인한 인건비 증가 등, 현금 흐름 감소라는 결과로 이어지게 됩니다.
기업이 비즈니스의 주요 중단 사태를 예상하지 못하고 적절하게 해결하지 못한다면 예기치 않은 재해 발생으로 장기간의 부정적인 결과와 영향을 초래할 위험성이 있습니다.
DR 계획을 제대로 수립하면 아래와 같은 다양한 리스크를 해소할 수 있습니다.
고가용성에 대한 기업의 의존도가 더 커지는 반면, 다운타임 허용도는 현저히 낮은 상태입니다. 따라서 많은 기업이 DR을 제대로 수립하여 부정적인 재해 효과가 일상 업무에 영향을 주지 않도록 하려 합니다.
DR과 다운타임의 두 가지 중요한 측정법은 아래와 같습니다.
일단 RPO와 RTO를 확인하고 나면 관리자들이 두 가지 측정법을 사용하여 최적의 재해 복구 전략, 절차, 기술을 선택할 수 있습니다.
엄격한 RTO 기간 중 운영을 복구하려면 기업에서 쉽고 빠르게 액세스할 수 있도록 보조 데이터를 최적으로 배치해야 합니다. 데이터를 빠르게 복원하는 데 사용되는 한 가지 방법은 적절한 복구(recovery-in-place)로, 모든 백업 데이터 파일을 라이브 상태로 옮기기 때문에 네트워크 전체에 걸쳐 이동할 필요가 없습니다. 이와 같이 서버 및 스토리지 시스템 오류로부터 보호할 수 있습니다.
적절한 복구(recovery-in-place)를 사용하기 전에 기업은 다음 세 가지를 고려해야 합니다.
적절한 복구(recovery-in-place)에 최대 15분이 소요될 수 있으므로 복구 시간을 단축하려면 복제가 필요할 수도 있습니다. 복제는 A라는 시스템 서버에서 B라는 서버로 데이터베이스를 복사하거나 정기적으로 온라인 새로 고침을 수행하는 것을 의미합니다. 이렇게 하면 네트워크의 모든 사용자가 동일한 정보 수준을 공유하게 됩니다.
재해 복구 계획은 계획하지 않은 보안 사고에 대응하여 지침을 제공하기 위해 체계적으로 문서화된 접근법입니다. 재해의 영향을 최소화하기 위한 예방 조치로 구성된 단계별 계획으로, 기업은 이를 통해 신속하게 미션 크리티컬 기능을 재개하거나 계속해서 평소처럼 운영할 수 있습니다.
일반적으로 DRP에는 모든 비즈니스 프로세스와 연속성 니즈에 대한 심층 분석이 포함됩니다. 기업은 상세한 계획을 수립하기 전에 먼저 리스크 분석(RA)과 비즈니스 영향 분석(BIA)을 수행해야 하며, RTO와 RPO도 설정해야 합니다.
복구 전략은 비즈니스 레벨에서 시작해야 하며, 이를 통해 기업 운영에 가장 중요한 애플리케이션을 결정할 수 있습니다. 복구 전략은 보안 사고 대응을 위한 기업의 계획을 정의하는 한편, DRP는 대응 방법을 자세하게 설명합니다.
복구 전략을 결정할 때는 아래와 같은 문제를 고려해야 합니다.
경영진은 모든 복구 전략을 승인해야 하며, 조직의 목표 및 목적에 맞춰 조정해야 합니다. 복구 전략을 개발하고 승인한 후에는 DRP로 변환할 수 있습니다.
이 DRP 프로세스는 단순히 문서를 작성하는 것 이상을 의미합니다. 비즈니스 영향 분석(BIA)과 리스크 분석(RA)을 통해 DRP 프로세스에서 리소스를 집중할 영역을 결정할 수 있습니다.
BIA는 중단 사고가 미치는 영향을 확인하기 위해 유용하며, 이는 DR 상황에서 리스크를 식별하는 시작점이 될 수 있습니다. 또한 RTO와 RPO를 생성하는 데 도움이 됩니다.
리스크 분석은 BIA에서 강조한 프로세스와 시스템의 정상 운영을 방해할 수 있는 취약점과 보안 위협을 식별합니다. RA는 중단 사고의 발생 가능성을 평가하고 잠재적인 심각도를 간략히 설명합니다.
DR 계획 체크리스트 단계는 아래와 같습니다.
기업은 필수 연락처 목록과 필요한 모든 중요 조치 단계 요약과 함께 DRP를 시작합니다. 중요 정보에 쉽고 빠르게 액세스할 수 있습니다.
이 계획은 팀 구성원의 역할 및 책임을 정의하고 조치 계획을 실행하는 기준도 간략히 설명합니다. 그런 다음 대응 및 복구 활동을 세부적으로 지정해야 합니다. 그 외 DRP 템플릿의 필수 요소는 아래와 같습니다.
DRP는 범위를 지정할 수 있습니다(예: 기본 범위부터 통합 범위까지). 경우에 따라 100페이지가 넘을 수도 있습니다.
DR 예산은 시간이 경과하면서 크게 달라질 수 있습니다. 이에 따라 기업은 미연방 재난 관리청(Federal Emergency Management Agency)으로부터 온라인 DR 계획 템플릿 같은 무료 리소스를 활용할 수 있습니다. 온라인에는 무료 정보와 방법에 대한 자료도 많이 제공됩니다.
DRP 목표 체크리스트에는 다음이 포함됩니다.
아무리 사소한 계획이라도 일상 업무 운영에 미치는 부정적인 영향을 최소화할 수 있어야 합니다. 또한 직원들이 예기치 않은 보안 사고가 발생했을 때 따라야 할 필수적인 비상 단계를 숙지해야 합니다.
이때 거리가 중요함에도 DRP 프로세스에서 간과되는 경우가 많습니다. 편의성, 비용, 테스트, 대역폭 등의 관점에서 볼 때 기본 데이터 센터에 가깝게 DR 사이트를 두는 것이 이상적입니다. 정전은 범위가 전혀 다른 문제로, 심각한 지역적 사고가 발생했을 때 기본 데이터 센터와 해당 DR 사이트가 서로 가까이 있으면 둘 다 파괴될 수도 있습니다.
해당 환경에 따라 DRP를 조정할 수 있습니다.
테스트를 통해 모든 DRP를 입증하며, 계획의 결점을 확인하여 재해가 발생하기 전에 문제를 해결할 수 있는 기회를 제공합니다. 또한 테스트는 해당 계획의 효과를 입증하고 RPO에 맞춥니다.
IT 기술과 시스템은 계속하여 변화합니다. 따라서 테스트를 통해 기업의 DRP가 최신 상태인지 확인해야 합니다.
DRP를 테스트하지 않는 이유로는 예산 제한, 경영진의 승인 부재, 리소스 제한 등이 포함됩니다. DR 테스트에는 시간과 계획, 리소스도 필요합니다. 이때 라이브 데이터를 사용하므로 보안 사고가 발생할 위험도 있습니다. 하지만 테스트는 절대 무시해서는 안 될 DR 계획의 중요 단계입니다.
DR 테스트는 단순 테스트에서 복합 테스트까지 다양합니다.
기업은 DR 정책에 따라 테스트 일정을 예약해야 하지만, 이때 방해 요소에 주의해야 합니다. 이는 테스트를 너무 자주 시행하면 생산성이 저하되고 인력이 낭비될 수 있기 때문입니다. 반면 테스트 주기가 너무 긴 것도 위험합니다. 중대한 시스템 변경이 수행된 후에는 항상 DR 계획을 테스트하도록 하십시오.
테스트를 최대한 활용하려면 다음을 수행하십시오.
재해 복구 서비스(DRaaS) 는 클라우드 기반 DR 방식으로, 최근 몇 년간 인기를 모으고 있습니다. DRaaS가 비용을 절감하고 구축이 용이하며 정기적인 테스트를 할 수 있기 때문입니다.
클라우드 테스트는 공유 인프라스트럭처에서 실행되면서 기업의 비용을 절감합니다. 또한 상당히 유연하여 필요한 서비스만 등록하고 임시 인스턴스만 가동하여 DR 테스트를 완료할 수 있습니다.
DRaaS의 예측과 요건은 SLA(서비스 수준 계약)에 문서화되어 있습니다. 타사 벤더는 사용량에 따른 지불 기준 또는 계약을 통해 자사의 클라우드 컴퓨팅 환경에 페일오버를 제공합니다.
하지만 대규모 재해 발생 후 클라우드 기반 DR은 사용하지 못할 수 있는데, 이는 해당 DR 사이트에 모든 사용자의 애플리케이션을 실행할 공간이 충분하지 않을 수 있기 때문입니다. 또한 클라우드 DR에서 대역폭 수요가 증가하므로 복잡한 시스템을 추가하면 전체 네트워크의 성능이 저하될 수 있습니다.
클라우드 DR의 가장 큰 단점은 아마 기업에 프로세스에 대한 제어 권한이 거의 없다는 점일 것입니다. 즉, 정의된 RPO와 RTO를 충족하면서 보안 사고 상황 발생 시 DRP를 구현하는 것을 전적으로 서비스 제공업체에 맡겨야 합니다.
비용은 벤더별로 크게 다를 수 있으며, 벤더가 스토리지 소비나 네트워크 대역폭을 기준으로 비용을 청구하는 경우 더 올라갈 수 있습니다. 그러므로 제공업체를 선정하기 전에 철저한 내부 평가를 거쳐 기업의 DR 수요를 확인해야 합니다.
제공업체 선정 시 아래와 같이 질문하십시오.
기본 데이터 센터를 사용할 수 없는 경우 DR 사이트를 통해 기술 인프라스트럭처 및 운영을 복구하고 복원할 수 있습니다. 이러한 사이트는 내부 또는 외부가 될 수 있습니다.
기업은 내부 DR 사이트를 설치하고 관리할 책임이 있습니다. 이러한 사이트는 엄격한 RTO와 대규모 정보 요건을 보유한 기업에 반드시 필요합니다. 내부 복구 사이트를 구축할 때 고려해야 할 사항으로는 하드웨어 구성, 전력 유지 보수, 지원 장비, 레이아웃 디자인, 냉난방, 위치, 직원 등을 들 수 있습니다.
외부 사이트에 비해 훨씬 비용이 많이 들지만 내부 DR 사이트를 사용하는 경우 DR 프로세스의 모든 측면을 제어할 수 있습니다.
외부 사이트는 타사 벤더가 소유하고 관리하며, 다음 중 하나일 수 있습니다.
1980년대, SHARE Technical Steering Committee와 IBM(International Business Machines)은 DR 서비스 레벨을 설명하는 티어 시스템을 제시했습니다. 여기서는 티어 0일 때 오프사이트 회복력이 최저 수준이고 티어 6에서 최고 수준입니다.
DR 자동화를 포함하기 위해 7번째 티어가 나중에 추가되었습니다. 현재 이 시스템은 DR 시나리오에서 최고의 가용성 레벨을 나타냅니다. 일반적으로 복구 능력이 티어별로 향상되면서 비용 역시 증가합니다.
재해 대비는 쉽지 않습니다. 모든 것을 고려하되 소프트웨어, 하드웨어, 네트워킹 장비, 연결성, 전력 등을 아우르는 포괄적인 접근 방식을 사용하고 RPO와 RTO 목표 내에 재해 복구가 달성되도록 테스트하는 것까지 포함해야 합니다. 철저하면서 실행 가능한 재해 복구 계획을 구현하는 것은 만만치 않지만 그로 인한 잠재적인 혜택 또한 상당합니다.
회사의 모든 직원이 재해 복구 계획을 제대로 알고 있어야 하며 구현 중에 효과적인 의사 소통이 반드시 필요합니다. 기업은 DR 계획을 개발하고 이를 테스트하며 직원을 훈련하고 모든 사항을 정확히 문서화하면서 정기적으로 개선해야 합니다. 마지막으로, 타사 벤더의 서비스를 도입할 때는 주의해야 합니다.