랜섬웨어 시대에 문서화된 DR 계획이 시급한 이유

랜섬웨어는 재해복구 계획을 뒷방에서 전면으로 끌어올렸다. 허리케인, 토네이도, 지진의 피해를 입지 않을 것이라 생각하는 것은 이해할 수 있다. 하지만 기업이 랜섬웨어의 공격을 받지 않을 것이라 생각하는 것은 복권에 당첨될 것이라 생각하는 것과 같다. 기업이 랜섬웨어의 공격을 받을 확률은 매우 높기 때문에 사고 대응 계획에 포함된 견고한 재해 복구 계획이 필요하다.
 

수십 년간 이 업계에서 일하면서 배운 것이 있다면, 백업이나 복제본만 있다고 해서 진정한 의미의 재해 복구 계획이 수립된 것은 아니라는 것이다. 필자는 중요한 시스템 복구를 직접 겪었고, 추측만 하고 계획이 불완전할 때 어떤 일이 벌어지는지 목격했다. 특히 오늘날과 같이 랜섬웨어가 만연한 환경에서는 복구 준비는 타협할 수 없다.
 

복구 인프라의 사전 정의 

적절한 DR 계획은 완전히 새로운 인프라에서 데이터와 시스템을 복원해야 한다는 가정을 바탕으로 수립된다. 포렌식 상의 이유로 원래 시스템을 보존해야 하거나 하드웨어가 수리가 불가능해 사용할 수 없을 수도 있다. 공격이나 재해가 발생한 후 동일한 물리 서버를 재사용하는 것은 무모한 일이다. 불가능할 수도 있으므로 완전히 새로운 하드웨어로 복구를 시작할 준비가 되어 있어야 한다.

즉, 이벤트 발생 후 임시 배포를 위해 대기 장비 또는 장애 조치 호스트를 미리 확보해야 한다. 클라우드 인프라를 활용하는 것은 이를 위한 좋은 방법 중 하나인데, 구성을 미리 만들어 두고 필요할 때 비용을 지불하면 되기 때문이다. 혼란스러운 상황에서 교체 서버를 구입하기 위해 허둥대는 것은 위기를 더욱 키울 뿐이다. 따라서 교체 시스템이 실제로 필요하기 훨씬 전에 대체 시스템을 어디에서 가져올지 알고 있어야 한다.
 

페일오버 환경의 신속한 보호

사람들이 간과하는 또 하나는 페일오버가 발생한 후 DR 사이트를 백업하는 방법이다. 온프레미스든 클라우드든 DR 사이트로의 전환이 발생하면 새로운 환경에 대한 백업을 즉시 시작해야 한다. 중요한 시스템을 성공적으로 복구했는데, 백업 생성을 소홀히 해 2차 랜섬웨어가 DR 사이트까지 위험에 빠뜨리는 것은 누구도 원치 않을 것이다. 복구 하드웨어 구입 계획과 마찬가지로, 복구 사이트 역시 백업할 방법을 미리 결정하고 설계해야 한다. 또한, 복구 사이트에 장애가 발생하면 자동으로 백업이 시작되도록 설계하는 것이 가장 좋다. 레거시 백업이 다시 설정될 때까지 복구가 완료된 것으로 간주해서는 안된다.
 

가시적인 복구 기간 목표 정의

일반적인 비즈니스 책임자에게 어떤 종류의 복구 요구 사항이 있는지 물어보면 데이터 손실이 전혀 없는 즉각적인 복구(즉, RPO와 RTO가 0인 복구)가 필요하다고 말할 것이다. 하지만 이런 요구 사항을 충족하는 데는 천문학적인 비용이 든다. 따라서 어렵겠지만, 재해가 발생하기 전에 현실적인 복구 시간과 데이터 손실 허용 임계치에 대해 논의를 마쳐야 한다. 

조직의 우선순위를 조정하고 비즈니스 연속성 요구 사항과 실제 IT의 역량 및 비용 제약의 균형을 맞추기 위해 경영진의 이해관계자와 더 많이 논의할수록 복구가 더 성공적으로 이루어질 수 있다. '성공'은 상대적인 개념이므로 비즈니스에서 설정한 목표를 달성해야만 성공할 수 있다는 점을 기억하자. 이런 목표가 현실적이고 적절한 자금이 뒷받침된다면 성공으로 가는 길에 들어선 것이다.
 

의심 극복을 위한 문서화 및 테스트

목표가 정의되어 있더라도, 치열한 전투 상황에서는 문서화되고 입증된 실행 지침이 필수적이다. 데이터와 시스템을 대규모로 효율적으로 복원하는 방법을 이해하지 못하면, 단순히 백업 복사본이나 복제본을 보유하는 것만으로는 아무 소용이 없다. 시스템 종속성을 포함해 중요도 순으로 자산을 복구하는 단계별 절차가 필요하다. 또한 문서에는 복구 환경의 전체 인벤토리, 모든 직원 및 공급업체의 연락처 목록, 문제 처리를 위한 단계별 프로세스가 포함돼야 한다. 모의 시나리오에서 중요하고 반복적인 테스트를 하면, 가장 중요한 순간에 담당자가 이 문서를 활용해 가치를 실현하는 연습을 할 수 있다.
 

자동화보다 중요한 걸음마 단계

초기 DR 작업은 수동 절차가 주를 이룰 수 있지만, 자동화를 지속적으로 추진해야 한다. 프로그래밍 방식으로 스크립팅하거나 트리거할 수 있는 복구 작업이 많을수록 성공 확률이 높아진다. 하지만 최고만을 추구하면 오히려 독이 될 수 있다. 완전한 자동화를 추구하느라 초기 단계의 DR 계획 수립이 늦어져서는 안 된다. 아무것도 없는 것보다는 무엇이라도 있는 것이 낫다. 먼저 모든 것을 문서화한 다음 테스트 피드백을 바탕으로 시간이 지남에 따라 선별적으로 자동화를 추진하기 바란다. 마라톤의 결과보다 중요한 것은 걸음마 단계이다.
 

클라우드 활용

클라우드는 데이터 복제, 특히 임시 DR 인프라를 프로비저닝하는 데 높은 유연성을 제공한다. 클라우드 서비스를 사용하면 테스트 환경을 편리하게 가동 및 중단할 수 있어 재해 시나리오를 훨씬 쉽게 연습할 수 있다. 온프레미스 인프라를 사용하는 기업의 경우에도 DR 목적으로 클라우드 기반 백업 복제를 고려하기 바란다. 대부분의 경우, 클라우드는 이미 사이버 복원력 준비에 있어 중요한 역할을 하고 있으므로 재해 대비에도 클라우드를 적용하는 것이 좋다.
 

허점이 드러날 때까지 테스트

DR 문서가 있는 것은 좋지만 필요할 때만 테스트하는 것은 좋지 않다. 테스트의 또 다른 목적은 근육 기억을 개발하는 데 도움이 되는 것 외에도 프로세스의 부족한 부분을 찾아내는 것이다. 모의 재난을 통해 선제적으로 실패를 경험해 보는 것이다. 새로운 기능이나 절차를 검토할 때 때때로 발생하는 장애를 예상할 수도 있다.

29년 전, 딸이 막 태어났을 때 아내의 병실에서 전화가 걸려와 복구 작업을 도와달라는 요청을 받은 적이 있다. 문서화된 프로세스가 있었기 때문에 전화를 끊고 새 아이에게 집중할 수 있었다. 문서화된 복구 프로세스가 언제 필요할지는다. 하지만 지금이 바로 프로세스를 시작할 때다.
editor@itworld.co.kr