랜섬웨어(ransom malware)가 경찰 서버도 인질로 잡았다

에볼라, 메르스, 지카… 전국민이 바이러스전문가가 되어가고 있는 시대입니다. 스마트정보화시대의 엔진인 컴퓨터 장비들에 침투하는 바이러스들도 나날이 발전하고 있으며 우리나라에서는 2015년 초에 발견되면서 그 가공할 위력이 알려진 랜섬웨어는 컴퓨터전문가들 뿐만 아니라 경찰서와 같은 법집행기관까지도 협박하면서 우리 모두가 피해자가 될 수 있음을 보여주고 있습니다.

2014년 말 미국 매사추세츠의 스완지(프리미어리그 스완지시티와는 다릅니다. ^^) 경찰서는 인질로 잡힌 경찰서의 컴퓨터를 구하기위해 750달러를 지불하는 사건이 벌어졌습니다. 크립토락커(CryptoLocker)라는 랜섬웨어가 오염된 이메일을 통해 경찰서 컴퓨터에 침투해서 경찰서 컴퓨터를 사용할 수 없게되었습니다. 잘 모르는 사람에게서 온 메일의 첨부파일을 열면 위험하다고 계속 얘기하지만 우리는 늘 실수합니다. 특히 이메일의 경우 권위있는 정부행정기관의 이름과 문양 등으로 정교하게 위조된 이메일과 pdf 등의 형태로 변장해서 첨부되어있는 랜섬웨어를 직원들의 경각심만으로 완벽하게 막아내기는 어려워보입니다.

많은 직원들이 함께하는 기업의 경우는 더욱 조심해야하지만 애석하게도 랜섬웨어 같은 사이버위협에 효과적으로 대응할 수 있는 방안이 백업과 복구시스템을 준비하는 것 이외에는 마땅치 않습니다. 많은 기업들이 디스크나 네트웍 드라이브, 백업이미지를 활용합니다만 백업한 데이터가 이미 변형되었다면 복구할 수 없습니다. 랜섬웨어는 직원들 PC의 모든 데이터를 암호화시켜버리고 나아가서 네트웍으로 연결되어있는 드라이브들도 접근할 수 없도록 만듭니다. 클라우드에 있는 데이터까지도 안전하지 않습니다. 백업이 무용지물이 되어버립니다. 만약에 불순한 의도를 가진 사람이 네트웍 관리자의 장비로 침투해서 네트웍 접근권한을 가지게되면 기업의 네트워크 전체가 인질로 잡힐 수 있으며 이는 파일 몇 개 사용하지 못하는 것 보다 훨씬 심각한 사태가 생길 수 있다’고 미국 와이어드(Wired.com)의 패트릭(Patrick Oliver Graf)은 경고합니다.

많은 관련 기업들이 랜섬웨어의 위협에 대처하기 위한 방법들을 내놓고 있습니다만 아직 완벽해보이지는 않습니다. 마이크로소프트의 경우는 안티바이러스 기술에 중심을 두고 있는 것 같습니다만 이런 종류의 소프트웨어는 누군가 바이러스의 희생이 되고난 후 대응개발이 이루어집니다. 어떤 기업도 새롭게 개발된 랜섬웨어의 최초 감염자가 되어 안티바이러스 제품 개발에 이바지하고 싶어하지 않습니다.

랜섬웨어로부터 정보서비스를 지키기 위해서는 여러가지 노력과 준비가 필요합니다. 효과적인 안티바이러스 소프트웨어로 무장하고 조직구성원들에 대한 교육과 지속적인 경각심을 가지도록 하는 것이 그 첫번째 보호막입니다. 그리고 만약 이 보호막이 무너졌을 때 정상으로 돌아오기위해 우수한 복구시스템을 준비해야합니다.

온큐(onQ)는 랜섬웨어 등으로 망가진 정보시스템을 신속하게 원상복구하는데 최상의 제품입니다. 랜섬웨어가 감지되었다면 감염된 서버들을 네트웍에서 분리하고 치료를 해야합니다. 서버들과 기타 관련 장비를 치료하는 동안 평상시에는 네트웍에 접속되어 있지 않던 백업이미지로 기업의 정보서비스를 빨리 재가동함으로써 경영손실을 최소화할 수 있습니다. 온큐를 통해 정보서비스를 비상운영하고 있으므로 서버치료 또한 서두르지 않고 완전하게 수행할 수 있습니다.

랜섬웨어 등의 감염 뿐만 아니라 모든 종류의 재난상황에서 온큐은 정보서비스의 생존에 확신을 드립니다.

랜섬웨어? 그까짓 거…

랜섬웨어? 그까짓 거~

 

컴퓨터에 몰래 침입해서 데이터를 인질삼아 돈을 요구하는 랜섬웨어(ransomware code)가 점점 기승을 부리고 있습니다. PC사용자들을 먹이감으로 삼던 랜섬웨어 범죄자들이 휠씬 큰 피해를 담보로 훨씬 짭짤한 수익을 기대할 수 있는 기업의 서버들로 목표를 옮기고 있습니다.

랜섬웨어 범죄에 악용된 기업의 서버들이 2016년 1분기에만 35배나 증가한 것으로 알려집니다.

PhishMe의 보고에 따르면 2016년 3월 현재 피싱메일의 93%가 랜섬웨어를 이용한다고 합니다.

기업 임직원들을 이런 랜섬웨어 숙주 사이트나 피싱메일을 통한 랜섬웨어 감염에서 완벽하게 격리시키기란 무척 힘들어 보입니다.

이제 기상이변, 환경오염 등과 함께 랜섬웨어와도 싫어도 함께 살아가야할 모양입니다.

 

피할 수 없다면 즐겨라? 피할 수 없다면 그까짓 거로 만들어라

 

보안위협이 발달할수록 정보시스템을 구성하는 서버들 주변을 보안장비들로 벽을 쌓게됩니다. 각종 첨단 방화벽, 침입방지(IPS), 서버용 안티바이러스(anti-virus) 제품들로 보호막을 치게되고 또한 많은 정보보안 관련 안내서들이 그렇게 하라고 비슷비슷하게 알려주고 있습니다.

 

이러한 방식의 보안강화는 그 침투나 동작방식이 밝혀진 각종 보안위협들을 무력화시키는데 매우 효과적입니다. 반면에 무신경한 사용자들로 인해 생기는 보안장벽의 헛점이나 제로데이(zero-day) 랜섬웨어의 위협에는 별다른 효과를 기대하기 힘듭니다.

 

그런데 만약에 백업하고 있던걸 가지고 단순한 파일복구 수준 이상의 역할을 기대할 수 있다면, 그리고 더 나아가서 랜섬웨어가 망가뜨리기 전의 정상상태로 서버를 즉시 가동할 수 있다면, 어느 날 갑자기 찾아온 랜섬웨어의 위협과 기업정보시스템 마비의 재앙은 그까짓 거로 취급할 수 있게될것입니다..

 

온큐로 랜섬웨어의 협박을 무시하십시오.

 

온큐는 서버들을 OS부터 탑재된 각종 응용프로그램과 데이타 상태까지 그대로 온전하게 백업해두었다가 랜섬웨어로 서버가 마비되었을 때 즉시 가동할 수 있는 강력하고 간편한 백업재난복구(backup and disaster recovery) 제품입니다. 랜섬웨어의 망나니 짓으로 마비된 정보서비스를 정상으로 복구하는데는 몇 분밖에 걸리지 않습니다. 온큐로 정보서비스를 정상화시켜두고 천천히 망가진 서버들을 말끔하게 복구하면 됩니다.

onQconcept

 

 

 

 

 

 

어떻게 하는걸까요?                                                                        

 

1. 서버를 끄십시오

앗, 걸렸구나 싶으면 바로 서버를 끄십시오. 네트웍 선을 뽑아버리세요.

 

2.서버는 껐지만 해당 서버를 온큐에서 켜세요

온큐 관리화면에서 정상 시점의 해당 서버를 켜세요. 클릭 한 번이면 충분합니다.

즉시 정보서비스는 정상화됩니다.

 

3.랜섬웨어 무균청정 서버실로 만드세요

온큐로 서비스는 정상화시켰으니 문제가된 서버들과 같이 운영하는 다른 서버들까지도

천천히 악성코드 제거와 서버 정상화작업을 하십시오.

물론 이렇게 온큐가 서비스를 하는 동안에도 원래대로 백업은 정상 작동합니다.

 

4.랜섬웨어 사건발발 이전의 태평성대로 돌아가세요.

온큐에서 운영하던 서버를 소독멸균된 서버들로 다시 부어줍니다.

온큐로 서비스하는 동안 발생한 변동분만 돌아온 서버에 반영해줄 수 있습니다.

아니면 아예 전체복구(BMR)를, 경우에 따라서는 이기종 서버로 할 수도 있습니다.

 

온큐가 끝내줍니다. 랜섬웨어 피해만발시대.

온큐가 시작합니다. 랜섬웨어 불안제로시대.

2003 서버 마이그레이션의 절친, 온큐

오늘이 지나면 Windows Server 2003에 대한 지원이 종료됩니다. 이제 사고를 쳐도 보호자라고 누군가 나서서 구치소에서 꺼내줄 수 없게되었습니다. 많은 분들이 2003에서 최신 서버 운영체계로 이전(migration)을 생각하고 있습니다.

마이그레이션의 핵심은 안전입니다. 혹시라도 문제가 생긴다면 기업과 조직의 활동에 심대한 영향을 줄 수 있습니다. 지금 현재 시스템이 잘 보존되어 마이그레이션 중에 언제라도 필요하다면 원상 복구할 수 있어야하고 그 과정이 시행착오 없이 일사분란하게 진행되어야 마이그레이션의 완성도를 높이고 다운타임 등으로 인한 손실을 최소화할 수 있습니다.

1. 현황분석과 마이그레이션 도달 목표치 설정
마이그레이션에 따르는 위험요소를 최소화하고 매끄럽게 진행하기 위해서는 현재 서버 환경을 충분히 이해해야합니다. 급하게 서두르지 말아야합니다. 모든 서버들의 연결상태, 동작을 위해 필요한 서버들 사이의 의존성 등을 충분히 파악해야합니다.
데이터 손실 가능성은 특히 유념해야합니다. 이를 위해 현재 상태의 서버를 온큐로 그대로 복제해두는 것이 좋습니다. 혹시나 마이그레이션 진행 중에 문제가 발생한다면 온큐로 백업했던 시점으로 쉽게 돌아갈 수 있기 때문입니다.
현황분석과 백업을 한 후 마이그레이션 목표를 설정합니다. 어떤 서버를 어느 정도로 마이그레이션 할 것인지. 이를 기반으로 전체적인 마이그레이션 수행계획을 수립할 수 있을 것입니다.

2. 마이그레이션 예행연습
실제로 마이그레이션을 하기 전에 미리해보는 것이 좋습니다. 운영 중인 2003 서버에서 최신서버로 바로 마이그레이션을 했을 때 생기는 각종 시행착오는 서버의 다운타임과 마이그레이션의 완성도와 품질에 지대한 영향을 주게됩니다. 온큐에서 대상 서버를 테스트 모드로 가동한 후 이 서버를 대상으로 마이그레이션 작업을 수행해보면서 예측하지 못한 문제점들을 확인하고 해결방안을 마련한 후 실제 서버를 대상으로 마이그레이션합니다. 이런 예행연습과정을 통해 잠재적인 위험요소를 제거함은 물론 실제 마이그레이션에 소요될 시간도 가늠할 수 있을 것입니다. 물론 이 시간 동안에도 원래 2003서버는 실제로 운영되고 있으므로 다운타임 또한 줄일 수 있습니다.

3. 마이그레이션 실시
서버별 특성과 마이그레이션의 위험요소들을 감안하여 실서버를 대상으로 마이그레이션을 합니다. 이 때 2003 서버의 최종본을 다시 온큐로 백업받아두면 만일의 사태 때 정상적인 가장 최근 상태의 2003 서버로 언제든지 되돌릴 수 있을 것입니다.
또한 마이그레이션 하는 동안 2003서버를 내려야할 필요가 있다면 온큐로 2003서버의 역할을 대신함으로써 다운타임 시간을 줄일 수 있습니다. 이럴 경우 마이그레이션이 끝난 후 새 서버와 온큐에서 가동하고 있는 2003서버의 데이터 차이를 보정하는 절차가 필요하며 이 시간 동안에만 다운타임이 생길 것입니다. 온큐로 서비스 페일오버(fail-over)하면서 마이그레이션한 후 데이터 보정할 때의 다운타임과 온큐 페일오버없이 실제 마이그레이션 했을 때 예상되는 다운타임을 마이그레이션 수행담당자와 비교논의한 후 진행하는 것이 유효합니다.

4. 새 서버 가동
더 좋은 새 서버로 안전하게 이주하셨다면 치맥으로 동료들과 자축의 시간을 가지세요. 더불어 마이그레이션에 사용했던 온큐로 새로운 서버를 보호한다면 더욱 쾌적하고 든든할 것입니다.

소니사건과 온큐

북한과 관련된 것으로 알려진 최근의 Sony사건이나 Dropbox, iCloud사의 사례에서 보면 여전히 거대기업들 조차도 사이버테러리즘이나 해킹의 위협에서 기업의 정보시스템과 나아가서 고객을 지키는데 어려움이 있는 것 같습니다. 불미스러운 사건으로 기업의 정보시스템이 손상을 입고 관련 직원들의 업무가 멈추는 상황을 예상한다는 것은 공포스러운 일입니다. 이와 관련된 많은 정보보안기업들이 고가의 전문서비스를 각자 소개하고 있습니다만 비용이 만만치않습니다. 기업의 정보시스템 담당자들은 어떻게 하면 경제적인 비용으로 만약의 상황에도 기업의 정보혈관이 정상적으로 흘러가게 할 것인지 고민스럽습니다.
현실적으로 보면 Sony사와 같은 저작물 유출 보다는 코딩오류나 직원들의 실수 등으로 인한 정보시스템의 장애가 훨씬 가능성이 높을 것입니다.
장애가 생겨도 쉽게 정상상태로 돌아올 수 있도록 미리 준비해두는 것은 일종의 보험 같은 것입니다. 규칙적으로 정보시스템 전체의 스냅샷을 만들어두었다가 바이러스가 침투하기 전으로 돌아가는 것은 좋은 사례일 것입니다. 이런 간단한 준비마저 없다면 바이러스를 치료할 때 까지 감염된 서버운영을 중단해야하므로 그 시간 동안 해당 업무는 마비가 될 것입니다.
사이버공격에 대비한 정보보안에 투자를 생각하고 있다면 온큐가 여러가지로 도움이 될 수 있습니다. 보관하고 있던 스냅샷으로 순식간에 정보서비스를 정상화하거나 클릭 한 번으로 서버를 복구시킵니다. 또한 보안패치나 새로운 관련 응용프로그램을 전체 시스템에 실제로 적용하기 전에 테스트 모드로 안전하게 검증해볼 수 있습니다.

많은 기업에서 태풍이나 지진 등의 자연재해 뿐만 아니라 정보시스템의 건강유지를 위해서도 온큐를 많이 사용합니다. 온큐는 광범위한 위협에서 정보시스템과 고객의 데이터를 보호하고 위기상황에서도 정보시스템을 중지하지 않는 지속가능한 혁신정보경영시대의 착한 동반자입니다.

서비스장애 발생 원인 조사 보고서

지난 수 년 간 많은 자연재해들이 신문의 헤드라인을 장식했으며 그 피해들도 어마어마했습니다. 많은 생명들이 사라지고 보금자리가 파괴되는 가운데 기업들의 생존 또한 위협받게됩니다. 미시시피주의 Small Business Development Center의 관계자에 따르면 태풍들(카트리나와 리타)이 지나가고 나서 미시시피지역에 있던 작은 회사들 중 60%가 사라졌다고 합니다.

그러나 이러한 재난들이 중소기업에게는 태풍이나 지진, 폭풍 같은 자연재해만을 의미하지 않습니다.

지금부터 하드웨어 고장 같은 ‘재앙, 재난’이 얼마나 자연재해를 능가하는 피해를 줄 수 있는지 살펴보겠습니다.

재난(재앙)을 어떻게 정의하는가와 관계없이 한가지는 분명합니다. 재난으로 인해 발생하는 시스템의 다운타임은 중소기업에게 심각한 상황을 가져올 수 있다는 것입니다. 실제로 HP와 SCORE의 보고서를 보면 소규모 회사들의 경우 재난을 겪고나면 약 25% 정도가 문을 닫는다고 합니다. 흔히 인용되는 Aberdeen Group의 리포트에서는 중견기업의 경우 1시간 정도의 서버 다운만 있어도 약 9천만원($74,000)의 손실을 입습니다.  IDC의 경우도 시간 당 손실을 약8천5백만원($70,000) 정도로 비슷하게 잡고 있습니다.

그런데 불행하게도 시스템이 죽는 다운타임은 보통 1시간으로 끝나지 않습니다. 실제로 Harris Interactive사의 조사에서 IT담당자들은 시스템 복구하는데 보통 30시간 정도 걸린다고 말합니다. (기껏해야 10시간 정도로 생각하는 경영진들에게는 놀라운 일일겁니다.)

각종 재난들을 완전히 없애버릴 수는 없지만 피해는 줄일 수 있습니다. 지속적으로 시스템 상태를 테스트하면서 유사시에는 시스템의 데이터와 애플리케이션, OS를 즉시 복구할 수 있는 재난복구기술이야말로 기업의 이익과 고객, 신뢰를 지키는 유일한 안전장치입니다.

본 보고서에서는 하드웨어고장에서 자연재해에 이르는 다양한 재난들이 얼마나 자주 발생하는지그 동안의 조사 결과를 정리합니다.

Quorum사 고객지원센타의 고객들을 통해 수집한 실제 사례들이 생생하게 와 닿을 것입니다.

 

한 눈에 보는 조사결과

다음 그림은 시스템의 다운타임을 빈번하게 일으키는 4가지 주요 요인을 정리한 것입니다.

재난발생순위그림

하드웨어 고장

55%로 하드웨어 고장이 시스템 다운타임의 원인 중 가장 큰 비중을 차지합니다. 전원공급장치나 네트워크 컨트롤러, 하드디스크 등 많은 자원들을 여분으로 준비하고 있으므로 하드웨어 관점에서 안전할 것으로 생각할 수 있습니다만 여전히 빈틈이 많습니다. 요즘같이 매섭게 뜨거운 날 냉방장치가 고장난다면, 국가적으로 대규모 정전사태를 걱정하고 있는 이 때 전원이 끊어진다면, 생각지도 못하게 쥐 같은 것들이 어디 케이블이라도 뜯어먹었을 때 무슨 일이 생길지는 아무도 모릅니다.

많은 중소기업들이 SAN(Storage Area Network) 고장을 경험합니다. 대규모로 SAN을 구성하고 모든 스토리지서버들을 가상화해서 SAN 영역에 두는 것이 일반적입니다만, 불행하게도 이로 인해 SAN에 문제가 생기면 회사전체가 문제가 됩니다.

캘리포니아은행인연합회(CBA ; California Bankers Assoc.)의 IT매니저인 랜디 마테오(Randy Mateo)씨도 이런 하드웨어 고장을 크게 경험한바 있습니다. 2010년 어느날 CBA의 SAN에 있는 하드드라이브가 몇 개 고장난걸 알게되었습니다. 가상서버들이 죽기 시작했죠. 원래대로라면 가상서버들이 서비스를 대신하기위해 기동(failover)해야했습니다만 그렇지 못해서 더욱 낭패였습니다. 하드디스크가 고장나면 기본 SAN서버가 모든 가상서버들과 데이터에 영향을 준다는 것을 알게되었습니다. “ 말할 필요도 없이 엄청난 일이었습니다. 가상서버들을 다시 살릴 수도 없어서 모두 새로 구성해야했습니다. “

마테오씨는 다행히도 가상화 플랫폼에서 제공하는 수동 백업기능으로 대부분의 가상서버들을 백업해두고 있었습니다. 그러나 Exchange 서버는 또 다른 문제였습니다.

“ Exchange 서버는 너무 커서 복구에 시간이 걸려서 최소 하루정도는 서비스를 못할 것 같았습니다. 그런데 복구하는데 실패하고 다시 세팅해야했습니다. 꼬박 사흘 반을 복구하는데 썼고 당연히 서비스를 못했습니다. “

 

인적 오류

모든 재난상황이 기술적인 부분에서 발생하지 않습니다. 재난원인의 22% 정도는 인적오류가 차지합니다. 실수로 서버의 파일시스템을 지워버리는 것 등이 여기에 해당됩니다.

ooops이런 인적요류는 흔히 신입사원이나 초보자들에게 일어난다고 생각할 수 있지만 꼭 그렇지만은 않습니다. 플로리다의 어떤 회사 임원의 경우 메일박스를 모조리 날려버리는 실수를 몇 번이나 했습니다. 주기적으로 서버를 백업하는 재난복구시스템을 사용하고 있었던 덕분에 중요한 메일들을 지킬 수 있었던 것이 다행입니다.

 

소프트웨어 오작동

소프트웨어 문제가 3번째 주요 원인으로 꼽혔습니다. 이는 패치가 얼마나 자주 일어나는가를 생각해보면 놀랄 일도 아닙니다. 이 소프트웨어와 관련된 문제는 패치를 적용하기 전에 제대로 테스트를 해보지 않기 때문에 주로 일어납니다. 패치로 인해 애플리케이션이 손상되고 이는 전체 시스템을 다운시키거나 접속을 못하게 됩니다.

운영체제(OS)의 경우 조금씩 제성능을 발휘하지 못하다가 결국 작동을 멈추게 되는 경우가 많습니다. 그리고 바이러스와 악성코드도 무시할 수 없습니다. 실제로 2012년 상반기에 36%의 소프트웨어 공격이 중소기업을 대상으로 이루어졌고 이는 2011년도 같은 기간에 비하면 두 배로 늘어난 숫자입니다. 이런 공격으로 네트워크 전체가 영향을 받고 결국은 회사업무가 마비됩니다.

소프트웨어 고장은 다양한 형태로 일어납니다. Sente Mortgage사의 IT임원인 Brent Schlueter씨는 최근 시스템 다운타임을 일으키는 소프트웨어 고장을 또 경험했습니다. 일상적인 소프트웨어 업그레이드를 하는 중이었는데 이전 버전으로 돌아가야할 필요가 생겨 작업하던 중에 SQL 데이타가 손상되었다는 것을 알게되었습니다. 이게 결국은 근본적인 파일구조에 까지 영향을 주게되어 최소 4시간의 시스템 다운타임이 발생하게 되었습니다. 덕분에 직원들은 빨리 평소보다 빨리 퇴근했습니다.

 

자연재해

태풍우리는 보통 재난, 재해라는 말을 들으면 우선 지진이나 태풍 같은 것을 떠올리게 됩니다. 반면에 자연재해가 전체 재난발생 원인의 5% 정도만 차지하고 있는 것을 보면 의외이긴 합니다만 그 파괴력에서는 비교할 수 없습니다.  HP와 SCORE의 보고서를 보면 자연재해로 인해 대규모로 데이터를 잃어버린 기업들의 70% 정도는 1년 안에 없어집니다.

유명한 인력채용회사인 24 Seven의 경우 일찌감치 재난복구시스템을 구축하고 주기적으로 실전사태에서 제대로 잘 동작할 수 있을지, 재난대비훈련을 해왔습니다. 덕분에 2012년 10월 초대형 태풍인 샌디가 공격했을 때 뉴욕의 본사는 근무를 할 수 없었지만 중요 업무들은 평소대로 운영할 수 있었습니다.

 

결론

재난이란 단순히 자연재해만을 말하는 것이 아니며 따라서 언제든지 일어날 수 있습니다. 그렇기때문에 대비해야 합니다. 그리고 적절한 관련 제품을 선택해야합니다. 실제 상황이 벌어졌을 때 제대로 다운타임을 줄일 수 있어야하기 때문입니다.

평소에 정기적인 테스트 또한 매우 중요합니다. IT관리자들은 번거롭고 복잡할 뿐만 아니라 시간도 많이 걸려서 이런 테스트를 싫어합니다. 따라서 관련 제품을 고를 때는 자동으로 간단하게 재난상황테스트를 할 수 있어서 재난상황에 대한 자신감을 심어줄 수 있는 제품이 좋습니다.

다이하드 의료정보시스템

점점 더 심해질 것으로 많이들 예견하고 있습니다만 전세계적으로 많은 기상이변들이 일어나고 있습니다. 1년 전 이맘때쯤 미국 미주리주에서는 토네이도 태풍으로 140명 이상이 사망하고 그 지역 대표 병원 중 하나인 세인트존스병원(St. John’s Regional Medical Center)의 시설 또한 대부분이 파손되는 큰 피해를 입었습니다. 병원 일부 건물이 약 10㎝ 정도 움직이고 110㎡ 정도 규모로 운영하던 데이터센터(Data Center) 또한 완전 붕괴되었습니다.

우리나라도 기상이변이 가져오는 예상하지 못한 위험들에서 자유롭지 않습니다. 가공할 위력의 지진이나 다른 나라에서 볼 수 있는 블록버스터급 토네이도 같은 재앙은 드물지만 집중호우 만큼은 매년 그 위력이 커지는 것 같습니다. 작년에는 60여 년의 역사를 지닌 국내 최대 규모의 재활병원이 설립 이래 처음으로 경안천 범람으로 물난리를 겪고 병원업무가 마비되는 초유의 사태를 겪기도 했습니다.

여기에 더해 우리나라의 경우는 자연재해와 더불어 경계해야하는 정치적, 군사적 위험요인도 있습니다. 누구도 예상하지 못했던 마른 하늘의 날벼락 같은 연평도 포격사태 같은 망연자실이 그것입니다.

비상대책위원회를 꾸며 보겠습니다.

세인트존스병원

 

 

 

 

 

    <토네이도로 완파된 세인트존스병원, 2011>

 

비상대책위원회

등장인물 : 챠트맨, IT맨1, IT맨2, 경비원

챠트맨 : 지금부터 완전통뼈병원의 비상대책회의를 시작하겠습니다. 현재 범인은 우리 병원의30대 서버 중 한대에 폭탄을 설치하였으며 10시간 안에 현금 100억을 가져오지 않으면 폭파시키겠다고 합니다. 서버를 열거나 움직이면 바로 터집니다. 우선 10시간 안에 모든 시스템을 다른 곳에서라도 정상 동작할 수 있도록 하는 것이 급선무입니다.

IT맨1 : (탕!) 야 안돼~ 생각을 해봐, 우리 서버들 그거.. 서버 회사 다 다른거 알지? 전화해서 10시간 안에 우리 서버들과 똑같이해서 운영할 수 있게 만들어주세요… 그러면.. 아, 네, 기다리고 있었습니다. 내일 바로 해 드리겠습니다. 그럴꺼 같애? 아, 네.. 그런데 그거 서버가 모델이 바뀌어서요.. 그거랑 같은 걸로 이중화로 구성하시려면 좀 찾아봐야 되는데요… 미국도 좀 갔다와야되고.. 이번 기회에 전부다 바꾸시죠? 그러지.. 거기다가 이거 저거 프로그램 깔다가 뭐가 있니.. 없니.. 되니.. 안되니.. 돈은 돈대로 꼽배기로 들건데.. 그런데 어떻게 10시간 안에 한다는거야… 안되에~

IT맨2 : (탕!) 야 나도 안돼~ 시간 안에 어찌어찌 똑같이 만들었다 치자. 10시간 지나면 터질거 아냐? 그럼 우리 시스템들 다시 가장 최신 상태로 만들어야 되는데.. 그게 보통일이냐? 동종 서버 구해서… 진단검사파일 같은거, 환자들 의료정보, 진료예약정보, 맞춰야지.. 처방프로그램 제대로 살려야지.. 수납데이타랑 사용인증서버 동작도 아무일 없었단듯이 정상화 해야하는데.. 너랑 나랑 다 붙어도 그거 하는데만 100시간도 더 걸리겠다.. 범인을 빨리 잡는게 낫겠다.. 이거 사람 불러야되.. 범인 잘 잡는 사람으로다.. CIS 불러.

경비원 : 지금 뭐 하시는 겁니까? 째깍째깍 폭탄 시계가 돌아가고 있는데.. 지금 부턴 내 지시에 따른다. 빨리 폭탄을 찾아서 해체하는 것이 급선무다. 개는 사람 보다 청각이 5배 이상 뛰어나다. 우리집 뽀삐를 서버실에 풀어서 폭탄부터 찾는다. 알겠나?

챠트맨 : 전자시곕니다.

경비원 : 구뤠? 요샌 전자 아닌게 없더라..이거 안돼..

 

재난대비시스템(Disaster Recovery) 선택 기준 3가지

과장된 상황이긴 합니다만 중단없는 안심의료정보서비스를 위해 재난대비시스템을 준비할 때 고려해야 할 주요 사항들이 거의 언급되었습니다. 이제 재난대비시스템을 구축할 때 도움이 될만한 3가지 기준을 살펴보겠습니다.

  1. 어떻게 보다 경제적으로 재난대비시스템을 구축할 것인가

언제 써먹을지도 모를 재난대비시스템의 존재이유를 고려한다면 비용요인이 큰 비중을 차지하게 됩니다. 그러다 보면 예산을 아끼기 위해 좀 덜 중요한 서버를 가려내고 재난대비계획에서 제외합니다. 미국기업의 경우에 운영 중인 서버자원의 20%만이 보호되고 있는 것이 이런 이유 때문일 것입니다. 반면에 의료정보서비스를 운영하는 입장에서 보면 중단 없이 원활하게 서비스를 운영하는데 크든 작든 기여하고 있으므로 모든 서버시스템들은 보호받을 가치가 있습니다.

예산에 맞추어서 어떤 서버는 재난상황에 대비하고 어떤 서버는 제외할까요?

애정남에게 물어봐야 할까요?

유사시에 서버를 보호하고 정보서비스를 유지하기 위한 산업계의 움직임은 크게 2가지 방향으로 발전해왔습니다.

첫번째 방향은 여유로 하나 더 시스템을 준비해두거나 똑 같이 복사해두는 것입니다(infrastructure mirroring). 서버자원들을 몽땅 똑같이 하나 더 만들어두고 계속 복사한다면 최고 수준의 재난대비상태일 것입니다.

두번째 방법은 서비스 구성요소 중에서 데이터만 따로 다른 저장공간에다 복사해두는 백업(backup)개념의 기술입니다.

서버자원을 몽땅 똑같이 하나 더 만들어두는 개념은 최상의 성능과 안전을 보장하겠지만 예상하시는 것과 같이 비용에 큰 결심이 필요합니다. 본능적으로 원래 구축비용의 두 배를 산정하게 됩니다만, 설계와 이행에 들어가는 부가 비용과 유지보수 비용을 감안하면 쉽게 결정할 비용에서 멀어집니다.

거기에 비해 백업 기술 진영은 예전의 테잎 장치에서 점점 저렴해지고 있는 디스크로 매체를 옮겨가며 발전하고 있습니다. 비용이 매우 저렴하다는 장점이 있으나 복구(recovery) 성능이 좋지 않은 단점이 있습니다. 테잎이나 디스크에서 데이터를 추출하고 서비스할 서버에다가 설치하고 서비스할 수 있도록 구성하는데 복잡한 절차를 거치게 되므로 시간이 많이 걸립니다. 그리고 데이터 손실 또한 발생합니다. 복구율이 채 70%도 안되는 경우도 종종 있는 듯 합니다.

 

  1. 재난대비 성능이 좋은가?

재난복구에 요구되는 기능은 크게 3가지입니다. 복제성능(replication)과 장애서버대체성능(failover), 장애서버복구성능(failback)으로 살펴볼 수 있습니다.

돌이켜보면 비상시의 서비스 복구와 관련한 대부분의 관련 기술들은 서비스 중인 서버를 어떻게 효과적으로 복제(replication)할 것인가에 중심을 두고 발전해 온 듯 합니다.

이러한 기술은 매일 테잎으로 백업하는 제품들부터 더 복잡한 SAN(Storage Area Network)기술을 이용한 제품까지 다양하게 소개되고 있습니다만, 현실에서 대부분의 정보시스템 운영담당조직은 다른 두 가지 성능요소인 장애서버대체성능(failover)과 장애서버복구성능(failback)에 더 큰 관심을 보입니다.

좋은 장애서버대체성능(failover)나 훌륭한 장애서버복구성능(failback) 기술이라면 그 기반에는 탁월한 복제(replication) 성능이 뒷받침 되어야 할 것이므로 당연하다고 생각됩니다.

 

여기서 장애서버대체(failover)와 장애서버복구(failback)가 무엇인지 간단하게 되짚어 보겠습니다.

장애서버대체(failover)는 서버의 장애가 발생했을 때 유사시를 대비해 준비 중이던 보조 시스템을 가동하여 중단 없이 계속 정보서비스를 제공하는 일입니다.

장애서버복구(failback)는 서버 장애로 발생한 비상 운영 상황이 종료되어서 정상적인 서버 운영 상태로 되돌려 놓는 일로 요약할 수 있습니다. 망가진 원래 서버를 고치거나 새로운 서버를 도입하고 나면 장애 중에도 발생한 운영상황을 반영하여 정상적으로 서버가 동작하도록 하는 것에 많은 노력이 요구됩니다.

장애서버대체(failover)를 위해서 소개되고 있는 제품들을 보면 대부분 여분으로 별도 장비를 사용하는 접근방식을 취합니다. 그러다 보니 구조적으로 좀 더 복잡해지고 비용이 높아지는 현상이 발생합니다. 이를 피하기 위해 비용효율이 좋은 백업(backup) 기술을 많이들 사용하게 됩니다만 장애서버대체(failover) 시간이 오래 걸리고 오류 발생 빈도도 높습니다. 아마도 원시 데이터(raw data)를 서버에서 서비스 가능하도록 변환하는 데서 발생하는 단점이라고 생각이 됩니다만, 어쨌거나 적당한 비용에 납득할 만한 장애서버대체(failover) 기능을 구현하는 것에 많은 관심들이 모아지고 있습니다.

장애서버복구(failback)는 재난대비절차의 마지막 단계입니다만 흔히들 재난상황을 가정하고 수립하는 계획에서 많이 빠뜨리게 됩니다. 많은 관련 제품들, 특히 백업 기반 제품들을 중심으로 계획을 수립하다 보면 장애가 발생하여 중단된 서비스를 빨리 재개하는 쪽으로만 관심을 두게 됩니다. 그러다 보니 중단된 서비스를 복구하고 나서는 다시 원래의 정상 운영 구조로 돌아가기가 어려워집니다. 수리가 끝난 장애서버를 현재 시점으로 재설치하는 일이나 혹은 완전히 새로운 서버를 도입하면서 발생하는 예상하지 못했던 어려움들을 겪게 됩니다.

  1. 평상 시에도 재난대비시스템의 테스트가 쉬워야한다

재난대비시스템을 구축하고 나면 이 시스템이 잘 동작하고 있는지 확인할 필요가 있습니다. 이를 위해 재난 대비 훈련을 하기 마련입니다만 보통 연중 1~2회로 그치는 경우가 많습니다. 이러한 재난 대비 훈련 횟수는 기술의 발전 추이나 기업 및 조직의 경영 변화와 이에 따라 진화하는 정보 시스템의 잦은 변경에 비추어 볼 때 터무니 없이 낮은 수치입니다. 안하는거 보다는 나은 수준입니다만 자주 많이 하고 싶어도 하지 못하는데는 이유가 있습니다. 많은 관련 기술들이 장애서버대체(failover)를 어떻게 효과적으로 할 것인가, 에만 관심을 두는 것이 중요한 이유 중 하나입니다. 재난 상황으로 서버의 동작이 멈추었을 때를 가정하고 테스트하는데 따르는 실제 서비스 장애 가능성 등을 미리 염두에 두지 않은 시스템이라면 동작 테스트의 시행에 적지 않은 용기가 필요할 것입니다.

결론적으로 재난발생과 정상운영상태 복귀에 이르는 전 과정의 성능과 동작 상황이 확인이 된 재난복구기술을 채택하는 것이 바람직합니다. 너무 자주 테스트를 해야 하는 것도 적절하지 않지만, 비상시를 대비한 점검 작업을 수행해보지 않고서는 사용하고 있는 재난복구 기술의 문제점을 파악할 수도 없습니다. 일이 터지고 문제점이 보인다면 이미 늦었겠지요.

DRscheme_kor

1대로 서버 40대까지… 단숨에 재난에 대비한다

서버의 백업과 이중화 등으로 많은 제품들이 소개되고 있으나 최근 미국 쿼럼(Quorum)사의 온큐(onQ)에 많은 관심이 쏠리고 있습니다. 온큐는 가상화 기술을 기반으로 서버의 운영체제(OS), 애플리케이션 그리고 데이터까지 모두 통합해서 한번에 백업한 후 필요할 때 단숨에 복구하므로 재난상황에도 서비스를 빠르게 재개할 수 있습니다. 온큐 한 대로 대상 서버 40대까지.. 또는 그 이상도 간편하게 자동화된 툴로 보호할 수 있다는 점이 인상적입니다. 전통적인 하드웨어 기반 서버는 물론 VM웨어, MS하이퍼V, Citrix 젠서버 등 모든 가상화 플랫폼을 지원합니다. 또한 온큐는 서버 하드웨어와 재난대비기능 발휘를 위한 소프트웨어가 최적으로 통합된 장비(appliance) 제품이므로 다양한 서버환경에서도 쉽고 간단하게 재난대비시스템을 구축할 수 있습니다. 서비스되고 있는 운영시스템에 영향을 미치지 않고 재난복구 테스트를 할 수 있으며 사용에 필요한 모든 소프트웨어 라이선스가 포함되어 있으므로 비용적인 면에서도 부담이 없습니다.

QuorumLogoonQ

 

 

 

 

한국과학기술정보연구원(KISTI)의 김주영 정보시스템운영팀장은 ‘재난대비시스템을 구축할 때 고려해야 하는 점이 매우 많습니다. 주센터에 맞는 하드웨어 사양부터 네트워크 확장, 백업과 복구 환경 설정, 재난대비시스템 관리인력 등 세밀한 부분까지 감안해야합니다. 재난대비시스템은 가급적 자동화되고 단순화된 환경을 만드는 것이 좋다고 생각합니다. 이러한 점에서 볼 때 하나의 장비에서 모든 프로세스가 자동으로 이루어지는 어플라이언스가 좋은 선택이 될 수 있습니다.’라고 조언합니다.

 

OS 패치만 달라도 재난대비시스템은 제대로 동작하지 않는다

2001년 9월 11일 오전9시 뉴욕 국제무역센터, 당시 미국의 기업 중 전산시스템 복구에 4일이상 걸린기업은 90%가 폐업한것으로 전해지고 하루 이상 걸린 기업 중에서도 많은 업체가 문을 닫았다고 합니다. 이후 재난대비시스템에 대한 관심이 높아지면서 많은 투자들이 이루어졌으나 정합성 불일치 등의 문제로 재난대비시스템의 정상적인 작동을 기대하기 어려운 경우가 많다고 합니다. 컴퓨터월드(2011.9.)에 따르면 재난대비시스템의 정합성에 문제를 일으키는 요인들은 패치버전의 불일치와 같은 아주 사소한 것인 경우가 많다고 합니다. 원격지 복제를 했는데 복제가 제대로 안 되고 있다거나, 복제를 해서 넘기려고 하는데 DB버전이 다르다거나, 하는 등의 사소함이 형식적인 모의훈련으로 인해 바로 시정이 되지 않고 있다는 것입니다.

주기적으로 대상 서버의 데이터는 물론 OS와 애플리케이션 까지 일치시켜주고 클릭 한 번으로 손쉽게 정상 동작 여부를 테스트해볼 수 있으며 강력한 장애서버복구성능(failback)을 가지고 있는 온큐에 많은 관심이 가는 이유입니다.