Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

재해복구

IDG 블로그 | 멀티클라우드로 “한 바구니의 달걀”을 피하는 법

최근 은행 업계는 클라우드 사용에 관한 여러 가지 의문에 직면했다. 우선, 단일 클라우드 서비스 업체의 자원에 집중하는 것이 은행을 위험에 노출시킨다는 우려이다. 만약 해당 클라우드에 대규모 서비스 중단 사태가 일어나거나 다른 여러 이유로 문을 닫으면 큰일이 아닐 수 없다. 이런 극단적인 상황 외에도 받아들일 수 없을 정도가 가격을 올린다거나 서비스 조건을 말도 안되게 바꿀 수도 있다.   규제 기관이 일부 퍼블릭 클라우드 서비스 업체에서 나오는 정보에 액세스할 수 없을 것이란 우려도 있다. 많은 클라우드가 다른 국가에서 호스팅되고 있다. 은행이 소유하지도 운영하지도 않는 컴퓨팅과 스토리지 자원에 집중했다가 고객과 투자자, 기타 이해 관계자에게 감당할 수 없는 위험을 가져올 수도 있다. 이들 위험에는 여러 차원이 있다. 만약 어떤 기업이 단일 퍼블릭 클라우드 서비스 업체로 가겠다고 하면, 단지 해당 클라우드에 종속되는 것만이 문제가 아니다. 더 걱정되는 것은 한 클라우드 서비스 업체로 해법 자체가 제한되는 것이다. 다시 말해, 여러 클라우드 서비스 업체 중에서 가장 좋은 솔루션을 이용하지 못하게 되고, 결국에는 덜 최적화된 아키텍처를 구성하고 만다.  하지만 은행 업계의 의문은 최적화된 최고의 솔루션을 만드는 것이 아니다. 여러 퍼블릭 클라우드를 사용하는 진정한 멀티클라우드 배치를 사용해 위험을 분산하는 것이다. 필자의 관점에서는 위험 분산이 문제 해결을 위한 최고의 기술만큼 중요하지는 않지만, 조금 더 고민해야 할 문제가 있다. 멀티클라우드는 재해 복구 측면의 가치가 있다. 많은 혁신적인 기업이 한 퍼블릭 클라우드 서비스 업체를 주력 시스템으로 이용하고 다른 곳을 보조적으로 이용한다. 같은 애플리케이션과 데이터에서 이런 구성은 시스템이 한 클라우드에서 다른 클라우드로 페일오버할 수 있다는 의미이다. 많은 경우, 최종 사용자는 백엔드 클라우드 서비스 업체가 자동으로 교체된 것을 알아차리지도 못할 것이다. 재해 복구를 위한 액티브-액티...

멀티클라우드 은행 위험성 2021.08.18

랜섬웨어 복구, 클라우드가 정답인 이유

랜섬웨어 공격을 받을 경우 몸값 지불을 피하는 가장 좋은 방법은 완전 자동화된 고속 재해복구다. 이 프로세스의 첫 번째 단계는 맬웨어 제거이고, 복구는 두 번째 단계다.  랜섬웨어 공격이 발생한 경우 사용할 수 있는 재해복구 방법은 크게 전통적인 복구, 이미지 기반 복구, 또는 클라우드 기반 복구의 세 가지로 나눌 수 있다. 그러나 대부분 환경에서 대규모 복구를 자동화할 수 있는 유일한 방법은 클라우드 복구 뿐이다.      전통적인 재해복구  전통적인 재해복구는 손실이 발생한 후, 즉 몸값 요구를 받은 이후 전통적인 복원에 착수하는 방법이다. 가상머신 이미지를 VM웨어, 하이퍼-V, KVM과 같은 하이퍼바이저 플랫폼 또는 AWS, 애저, GCP와 같은 하이퍼스케일러에 복원하는 경우도 전통적인 복원에 해당한다. 전통적이라는 말은 사건이 발생하면 그 이후에 복원을 시작한다는 의미다. 뒷에서 다루겠지만 데이터 복원이 필요하기 전에 복원하는 방법도 있다.  그다지 오래되지 않은 과거엔 모두가 이 방법을 사용했으므로 전통적인 방법으로 불린다. 대부분 기업에는 자체 복구 데이터센터를 운영할 예산이 없었으므로 필요할 때를 대비해 복구 데이터센터를 제공하는 서비스를 이용했다. 이 데이터센터를 실제로 이용할 때마다 비용을 지불해야 했으므로 미리 데이터를 복원한다는 것은 생각할 수 없는 일이었다. 재해가 발생할 때까지 기다렸다가, 발생하면 복구 데이터센터에 연락해서 복구를 시작했다. 복원을 수행할 하드웨어를 기업이 직접 소유하지 않으므로 속도가 느리고 자동화하기도 매우 어렵다.  이제 이 방법은 사용하지 말아야 한다. 데이터센터가 감염되거나 재해로 파손된 후 전체 데이터센터에 대해 전통적인 재해복구를 수행하는 데는 너무 오랜 시간이 걸린다. 랜섬웨어 공격을 받은 경우라면 몸값을 지불할 수밖에 없는 상황으로 내몰리게 된다. 몸값 지불은 좋은 해결책이 아니므로 너무 오랜 시간이 걸리는 재해복구 계획은 지양해야...

랜섬웨어 재해복구 RTO 2021.08.09

재해 복구 실행 이전에 해야 할 랜섬웨어 복구 프로세스

컴퓨팅 환경이 대규모 랜섬웨어 공격을 당할 위험이 있다면, 대부분 재해복구 계획을 세울 것이다. 하지만 시스템을 복구하기 전에 감염을 중단시키고 공격을 파악한 다음, 제거하는 작업부터 해야 한다. 복구 단계를 너무 성급하게 실행하면, 사태를 더 악화시킬 수도 있다. 성급한 복구가 문제가 되는 이유는 랜섬웨어가 어떻게 작동하는지를 이해하면 알 수 있다.     랜섬웨어가 확산하는 방법 랜섬웨어가 무슨 짓을 하는지를 설명하는 글은 많지만, 랜섬웨어의 목표가 단지 시스템 한 대를 감염시키는 것이 아니라는 사실을 강조하는 것이 중요하다. 현대화된 랜섬웨어 변종은 다양한 운영체제의 취약점을 찾아내 관리자 액세스를 확보하고 LAN의 나머지 영역으로 확산한다. 공격은 C&C 서버를 통해 조정되는데, 명령을 받기 위해 이들 서버와 접촉하는 것이 모든 랜섬웨어 변종이 제일 먼저 하는 일이다. 랜섬웨어 대응의 핵심은 이들 C&C 서버와의 추가 커뮤니케이션을 차단하는 것은 물론, 감염된 시스템과 LAN의 나머지 시스템 간의 커뮤니케이션도 차단하는 것이다. 지금 감염된 상태가 아니라면, 이제는 네트워크 환경에 맞춰 대응 계획을 세우고, 이를 재해복구 계획처럼 테스트해야 한다.    도움을 얻을 수 있는 곳 대규모 랜섬웨어 공격은 혼자서 막을 수 있는 것이 아니다. 지옥문이 열렸다고 느껴질 때, 이를 중단하고 복구하는 데 도움을 줄 곳은 많으며, 기업도 관련 기관이 범인을 체포하는 데 도움이 될 수 있는 조처를 취해야 한다. 랜섬웨어 대응 계획의 일부로 이런 곳의 연락 정보가 포함되어야 한다. 사이버 보험 정책이 있다면 매우 유용한데, 대응 과정에서 지침을 줄 수 있는 전문가와 연락할 수 있기 때문이다. 공격을 받기 전에 이들과 연락해 대응 프로세스와 문서를 구축하기 바란다. 이런 정책이 없다면, 새로 마련하는 것도 고려해야 한다. 지역 사법기관에도 즉각 연락해야 한다. 공격의 범위와 특성에 따라 이들 사법기관이 개입하는 정...

랜섬웨어 재해복구 프로세스 2021.07.13

기업의 재해 복구 및 비즈니스 연속성 계획을 뒤흔든 코로나19

코로나19 팬데믹은 원격 액세스, 네트워킹, SaaS 애플리케이션 및 랜섬웨어와 같은 영역에서 기업 재해 복구(Disaster Recovery, 이하 DR) 및 비즈니스 연속성(Business Continuity, 이하 BC)계획에 존재하는 구멍을 드러냈다. 지난 1년 동안 IT 경영진들은 수시로 이 구멍을 메우고 DR 계획을 업데이트하느라 분주한 시간을 보냈다.  또한 팬데믹은 많은 조직에서 근본적인 IT 변화를 촉발시켰다. 변화에는 클라우드로의 성급한 애플리케이션 마이그레이션, 디지털 트랜스포메이션 작업의 가속화, 전통적인 구매 절차를 생략한 긴급한 신규 시스템 및 서비스 프로비저닝, 그리고 많은 업계에서 개인 디바이스를 사용해 핵심 데이터를 다루는 정규 재택 근무 직원이라는 새로운 작업 형태의 부상 등이 포함된다.   액센추어(Accenture)가 새로 발표한 연구 자료에서 그룹 최고 책임자인 매니시 샤르마는 “기업 경영진의 4분의 3 이상이 직원의 업무 방식을 다시 설계하고 디지털 트랜스포메이션 계획을 가속화하고 고객과의 접촉 방식을 근본적으로 바꿀 계획을 갖고 있다”고 말했다. 조직은 2021년과 그 이후를 위한 DR/DC 계획을 다시 세울 때 이러한 모든 요소를 고려해야 한다. 팬데믹은 최악의 시나리오(또는 상상할 수 있는 수준보다 더 심각한 시나리오)가 실제로 발생할 수 있음을 보여줬다. 팬데믹은 재해 복구 및 비즈니스 연속성 계획에 영구적인 변화를 일으켰다.   시험대 오른 DR, BC 계획 대부분의 기업은 팬데믹 이전부터 재해 복구 계획을 두고 있었고, 많은 기업은 주요 인력이 모여 재해 시나리오에 대응하는 모의 훈련도 성실히 수행했다. 유행성 전염병 대응은 일반적으로 DR 계획에 포함된 시나리오다. 실제로 IT 서비스 관리 기업 엔소노(Ensono)의 글로벌 비즈니스 연속성 및 재해 복구 부문 책임자인 댄 존슨은 2019년 말에 클라이언트 현장에서 재해 복구 가산 훈련을 실시하면서 테스트 시나리오로 전염병 ...

재해복구 비즈니스연속성 DR 2021.05.06

클라우드 스토리지 재해로부터 얻은 백업의 교훈

유럽 최대 클라우드 서비스 업체인 OVH클라우드(OVHcloud)의 데이터센터에서 지난달 대형 화재가 발생, 데이터센터 하나가 완전히 소실되고 인접한 데이터센터 한 곳도 연기로 인한 피해를 입었다. 화재로 소실된 데이터센터에 데이터를 저장해둔 OVH클라우드 고객 중에서 자체 재해복구 수단을 두거나 OVH클라우드가 제공하는 오프사이트 백업 및 재해복구 서비스를 구매해 이용하는 고객은 운영을 지속할 수 있었지만, 그렇지 않은 고객은 잃은 데이터를 되찾을 방법이 없다.    완전히 손실된 사례도 있다. 예를 들어 rounq.com의 경우가 여기에 해당된다. 트윗에 따르면, 이 회사는 사전에 백업을 확보해 두었다고 하며, 아직 이를 기다리는 중이다. 반면 센터 퐁피두(Centre Pompidou)와 같이 어떤 형태로든 오프사이트 백업을 준비했던 기업은 비즈니스를 재개하고 있다.  두 가지 사례의 중간으로, 운영을 재개하긴 했지만 일부 데이터를 잃은 기업도 있다. 예를 들어 디스토피아적 게임인 러스트(Rust)를 판매하는 페이스펀치(Facepunch)가 있다. 러스트에서는 플레이어가 자기만의 가상 환경을 만들면 이 가상 환경이 서버에 파일로 저장되는데, 파괴된 데이터센터에 저장되어 있던 환경은 되찾을 수 없을 것으로 보인다.    클라우드는 없다  이번 사건은 클라우드 컴퓨팅의 현실을 적나라하게 보여준다. 클라우드라는 것은 없고, 결국 다른 누군가의 컴퓨터일 뿐이라는 현실이다. 여기서 다른 누군가가 클라우드 서비스 업체이고, 그 업체의 컴퓨터가 적절히 보호되지 않는다면 피해는 발생한다.  클라우드는 마법이 아니고 물리학과 혼돈의 법칙을 거스를 수 있는 것은 없다는 사실을 명심해야 한다. OVH클라우드는 데이터센터 화재를 예방하고 방지하고 화재 발생 시 진화하는 데 필요한 모든 요소를 갖추고 있던 것으로 보이지만, 그럼에도 역부족이었다.  IaaS, PaaS, SaaS 등 형태를 불문하고, ...

백업 화재 OVH 2021.04.27

비즈니스 연속성 및 재해 복구 계획 기본 가이드

캘리포니아의 산불, 텍사스의 폭설, 중서부 지역 곳곳의 겨울 강풍, 하와이의 홍수, 플로리다와 루이지애나의 허리케인, 러시아 해커와 랜섬웨어 공격, 그리고 전세계를 휩쓴 팬데믹 위기까지. 아직까지도 재해 복구와 비즈니스 연속성 계획이 크게 중요하지 않다고 생각한다면, 최근 일어난 사건들을 주목하지 않아서 일 것이다.  코로나19 팬데믹 위기를 벗어나기 시작하는 지금, 기업과 조직들은 원격과 디지털, 클라우드가 더 확대될 ‘뉴 노멀’에 맞춰 변화하고 있는 중이다. 재해 복구 계획 또한 변화하는 비즈니스 환경과 상황에 보조를 맞춰 변화할 것이다. 무엇보다 재해 복구를 위한 비즈니스 요건이 크게 바뀌었다. 며칠이나 몇 시간의 복구 시간이 수용되던 시절이 있었다. 그런데 지금은 몇 분이어야 한다. 일부 사업 단위(BU)는 예기치 않은 중단에 ‘0’의 다운타임을 요구한다. 2021년 이후의 재해 복구 및 비즈니스 연속성(DR/BC) 계획에 반영되어야 할 기본사항들을 소개한다 (정의에 너무 집착하지 말자. 재해 복구(Disaster Recovery, DR)란 IT 인프라를 백업에 가동하는 것, 비즈니스 연속성은 복구 후에 비즈니스를 되찾고 다시 기능하도록 만드는 더 광범위한 개념이다).      사이버 보안, 침입 감지/대응, 재해 복구를 데이터 보호 계획에 통합  CISO가 재해 복구 계획에서 첫 번째로 추구해야 할 목표는 애초에 재난을 피하는 것이다. 그런데 이는 갈수록 더 어려워지고 있는 목표이다. 무엇보다 데이터가 온프레미스 데이터센터에 안전하게 보관되어 있지 않다. 온프레미스 환경과 하이퍼스케일 클라우드, 엣지와 SaaS 애플리케이션 곳곳에 분산되어 있다. ESG 리서치(ESG Research)의 시니어 애널리스트인 크리스토프 버틀랜드는 SaaS는 데이터 보호와 복구 측면에서 상당한 도전과제를 제시한다고 지적했다. 이제는 미션 크리티컬 애플리케이션들이 통제할 수 없는 ‘서비스’로 운영되고 있기 때문이다. 둘...

재해복구 비즈니스연속성 DR 2021.03.29

랜섬웨어 공격에 대비할 수 있는 확실한 ‘백업’ 준비 방법

시스템을 랜섬웨어로 감염시킨 공격자에게 몸값을 지불하지 않는 가장 좋은 방법은 적절히 백업해 시스템을 삭제하고, 안전한 백업에서 복원하는 것이다. 백업이 랜섬웨어에 적합한지 확인할 방법을 소개한다. 이 기사에서 백업은 백업과 재해 복구를 지원하는 구형 백업 시스템과 복제 시스템, 최신 하이브리드 시스템을 비롯해 랜섬웨어 공격에 대응하기 위해 사용할 모든 시스템을 의미한다. 단순성을 위해 여기서는 모두 백업이라 지칭한다.     3-2-1 규칙을 통한 백업 무엇보다도 중요한 것은 ‘모든 것을’ 백업한다는 생각이다. 모든 새 시스템과 파일 시스템, 데이터베이스를 자동으로 포함하는 백업 시스템의 기능을 조사한다. 이는 호스트의 모든 VM이 나타날 때마다 자동으로 백업하도록 구성할 수 있는 가상화 세계에서 가장 쉬운 방법이다. 모든 것을 자동으로 포함하는 백업 시스템을 가장 잘 사용하는 방법의 하나다. 또한, 누가 구식이라고 말하든, 백업 시스템의 3-2-1 규칙을 따라야 한다. 이 규칙에 따르면 데이터의 복사본 또는 버전을 3개 이상 만들고, 2개 이상의 다른 미디어에 저장하며, 미디어 중 1개는 오프사이트에 있어야 한다. 주 시스템과 같은 위치에 백업을 저장하지 않는다. 더 좋은 방법은 다른 운영체제와 다른 물리적 위치에 저장하는 것이지만, 현실적으로 항상 가능하지는 않다. 백업 시스템에 어떤 유형이든 자동 보고 기능이 있어야 작업 중인 백업이 실제로 진행 중인지 확인할 수 있다. 보고에는 백업 성공과 실패가 모두 포함돼야 한다. 서드파티 모니터링 시스템이 가장 나을 수 있고, 모든 것을 지속적으로 살펴보고 상황이 조금 이상할 때 감지할 수 있다. 머신러닝을 사용하는 보고 시스템은 문제를 나타내는 패턴을 알아차릴 수 있어 이상적이다. 이렇게 하면 백업 시스템에서 매일 수십에서 수백 개의 이메일을 읽어야만 제대로 작동하는지 확인하기보다 쉽다.   DR 보안을 최우선 순위로 백업과 DR(Disaster Recovery) 시스템은 컴...

랜섬웨어 백업 사이버공격 2021.03.18

IDG 블로그 | “미션 크리티컬 클라우드”를 위해 준비해야 할 두 가지

클라우드리치(Cloudreach)와 IDC의 새로운 보고서 ‘클라우드 트렌드 2021(Cloud Trends 2021)’은 200명 이상의 CIO를 대상으로 설문조사를 실시했다. 설문은 주로 코로나19 팬데믹이 클라우드 컴퓨팅 활용 및 디지털 트랜스포메이션에 미친 영향에 중점을 두었다. 이 보고서를 후원한 클라우드리치는 클라우드 컨설팅 업체이다.    물론 “클라우드는 훌륭하다”라든가 “클라우드는 중요하다”라는 결론은 대부분 애널리스트의 보고서에서 쉽게 볼 수 있다. 하지만 퍼블릭 클라우드로의 대규모 마이그레이션이 “생존에 필수적”이라고 답한 CIO가 27.5%에 이른다는 점은 주목할 필요가 있다. 불과 5년 전만 하더라도 대부분 기업은 클라우드를 스토리지나 컴퓨트 같은 기술을 소비하는 선택지 중 하나로 여겼지, 정말로 필수적이라고 생각하지 않았다. 무엇이 변한 것일까? 코로나19 팬데믹으로 인한 봉쇄 조치가 처음 내려졌을 때, 전통적인 기업 데이터센터와 같은 물리 인프라는 불리한 요소가 됐다. 이들 인프라는 원격 근무를 지원할 수 있도록 확장하지도 못했고, 어떤 경우에는 서버를 교체하거나 전원을 수리하거나 네트워크 장애를 해결하러 데이터센터에 담당자가 직접 들어가지도 못하는 상황에 처하기도 했다. 기업의 IT 인프라 중 클라우드가 아닌 부분은 어려움을 겪었고, 위험성이 수용할 수 없는 수준으로 높아졌다. 기업은 이런 어려움에서 교훈을 얻었다. 2020년에 일어난 일은 다음 10년을 위한 전략 계획의 일부가 될 것이며, 퍼블릭 클라우드는 그저 기술 소비 방안 중 하나가 아니라 안전피난처로 여겨졌다. 이런 변화의 의미는 두 가지 정도로 정리할 수 있다. 첫째, 만약 클라우드가 필수적이라면, 무엇인가 잘못됐을 때를 위한 계획을 세워야 한다. 서비스 중단은 매우 드문 일이지만, 대부분 피할 수 있는 사용자 실수로 인해 발생한다. 클라우드 간의 리던던시는 물론, BC/DR 시스템을 계획하는 데 좀 더 공을 들여야 한다는 의미이다. 클라우드...

미션크리티컬 코로나19 멀티클라우드 2021.01.18

허리케인이 강타한 섬에서 얻는 재해 복구에 관한 교훈

허리케인이 미국의 한 바이오테크 회사가 ‘미션 크리티컬’ 시스템을 제어하기 위해 운영하는 2개 데이터센터가 위치한 섬을 강타했다. 이 바이오테크 회사는 40년의 경력을 가진 백업 전문가를 전용기에 태워 섬으로 보냈다. 여기서는 익명을 요청한 이 전문가가 이 섬에서 부딪힌 문제와 이를 극복한 방법을 소개한다. 편의상 전문가와 섬, 회사 이름은 모두 가명을 사용하며, 관련 솔루션 업체와 서비스 업체도 밝히지 않는다.   이니테크(가칭)는 아틀란티스섬(가칭)에 2개 데이터센터를 갖고 있었다. 약 200대의 가상 및 물리 시스템에서 실행되는 데이터의 양은 모두 400TB에 달한다. 백업 시스템은 업계 수위의 전통적인 백업 소프트웨어 솔루션 업체의 제품을 기반으로, 중복제거 디스크 시스템에 데이터를 백업한다. 각 데이터센터는 데이터를 자체 중복제거 시스템에 백업한 후, 다시 다른 데이터센터의 디스크 시스템으로 백업을 복제한다. 각 데이터센터에 이니테크가 아틀란티스 섬에 보관한 모든 백업의 전체 사본이 위치하기 때문에, 데이터센터 한 곳이 파괴되어도 이니테크는 여전히 모든 데이터를 보존할 수 있다. 또한 이니테크는 에어갭(Air Gap) 용도로 가끔 이들 백업을 테이프에 복사해 아틀란티스 섬에 보관한다. 본사가 있는 지역에 저장할 수도 있었지만 그렇게 하지 않았다. 다행히 이번 허리케인에 테이프가 파괴되지는 않았지만, 손상될 수도 있었다. 이니테크는 재해 복구에 클라우드를 이용하는 것을 고려했지만, 아틀란티스의 대역폭 제한 때문에 실용적이지 않다는 판단을 내렸다. 허리케인이 닥쳤을 때, 이니테크는 지상 현장에서 복구 프로세스를 지휘할 사람을 찾기 시작했다. 피해가 심했기 때문에 복구 프로세스를 완벽하게 지휘 통솔할 수 있는 사람이 필요했다. 이런 정도의 기술력을 가진 사람은 소수에 불과했고, 그중 한 명이 론(가명)이었다. 이니테크는 론을 전용기에 태워 아틀란티스로 보냈다.   물에 잠긴 데이터센터의 이전과 복구 아틀란티스 섬 전체적으로 피해가 ...

재해복구 DR 백업 2021.01.08

"OCI 서울 리전에 이어 춘천에 두 번째 클라우드 리전 개소" 진정한 엔터프라이즈 클라우드 시대 열린다 - IDG Summary

많은 기업이 클라우드를 도입하고 있지만, 기업 운영의 핵심 역할을 하는 미션 크리티컬 워크로드는 온프레미스 시스템에서 처리하는 경우가 많다. 현재 서비스 중인 퍼블릭 클라우드 대부분이 성능과 운영 안정성 요건 눈높이를 충분히 지원 못하기 때문이다. 설사 미션 크리티컬 워크로드를 클라우드로 이전한다고 해도 남는 우려가 있다. 바로 재해복구(Disaster Recovery)다. 결국, 오늘날 기업에 필요한 클라우드는 기존 1세대 서비스의 한계를 넘어 가용성은 물론 성능과 보안, 그리고 DR까지 믿고 사용할 수 있는 클라우드, 미션 크리티컬 애플리케이션과 워크로드까지 처리할 수 있는 엔터프라이즈 클라우드다.   주요 내용 - 클라우드, 이상과 현실 사이 - 재해복구는 미션 크리티컬 클라우드의 안전장치 - 오라클이 제시하는 2세대 클라우드, OCI - ‘1국가 2리전’의 진정한 의미 - 미션 크리티컬 엔터프라이즈 클라우드의 조건

OCI 춘천리전 재해복구 2020.08.14

IDG 블로그 | 재해복구와 클라우드 컴퓨팅에 대한 3가지 오해

IT 부서의 대부분은 백업과 복구 작업이 필요하다고 알고 있지만, 클라우드 환경의 백업은 약간의 혼란을 야기한다.   재해복구(Disaster Recovery, DR)는 애플리케이션이나 데이터가 프로덕션 환경에 배치될 때마다 해결해야 하는 주제 중 하나이지만, 형식적인 것에 그치는 경우가 적지 않다. 애플리케이션을 퍼블릭 클라우드에 배치할 때도 마찬가지이다. 하지만 약간의 혼란이 있다. 이 문제를 살펴본 결과, 클라우드 기반 재해복구에 관해 기업의 클라우드 마이그레이션을 방해하는 세 가지 커다란 오해가 있음을 확인했다. 오해 1. 퍼블릭 클라우드에 기본 내장되어 있기 때문에 DR이 필요없다 일부 기본적인 DR 기능은 퍼블릭 클라우드 서비스의 기본 시스템이라는 데 혼란의 원인이 있다. 퍼블릭 클라우드는 하드웨어 장애나 실제 재해에 대비한 백업 시스템이 있다. 하지만 이들 시스템은 각 테넌트를 점유한 워크로드의 특정 DR 요구를 고려하지 않는다. 이런 사실은 데이터가 사고로 지워지거나 실행 파일이 깨지기 전까지는 발견되지 않는다. 퍼블릭 클라우드 서비스 업체는 하드웨어 랙이 과전류로 불이 나는 등의 큰 문제는 살피지만, 어느 고객의 데이터베이스나 파일에서 데이터가 손실되는 것과 같은 작은 문제는 보통 다루지 못한다. 퍼블릭 클라우드 서비스 업체는 ‘공유 책임’ 모델을 내세우는데, 이에 따르면 퍼블릭 클라우드 서비스 업체는 클라우드 서비스를 위한 DR을 제공해 장애나 재해에도 서비스가 계속 돌아가도록 할 수 있다. 하지만 기업은 마치 실제로 가상 클라우드 서버를 보유한 것처럼 자사 데이터와 애플리케이션을 백업할 책임을 진다. 오해 2. 각 클라우드 서비스별로 DR 계획과 프로세스가 있어야 한다. 기업은 클라우드 기반 데이터베이스를 해당 데이터베이스 전용 데이터 가져오기/내보내기 툴을 사용해 백업할 수 있다. 하지만 이런 서비스가 20배로 늘고, AI 서비스나 IoT 서비스, 분석 서비스용으로 다른 DR 요구사항이 추가되면 엄청나게 복잡해진다.&n...

백업 재해복구 2020.06.10

코로나19 확산, 재해복구 계획을 점검하고 보완할 기회

백업과 재해 복구 시스템은 잠재적인 심각한 위험에도 불구하고 종종 가치를 인정받지 못하고 예산도 책정되지 않는 경향이 있다. 그런데 코로나19 사태가 이런 경향에 변화를 줄 것으로 기대된다. 질병에 대한 준비는 평상시 해야 하는 것과 크게 다르지 않지만, 코로나19에 대한 우려는 기존 계획을 더 구체화하거나 오래된 정책을 재고하는 데 도움이 될 수 있다.   원격 근무에 대비하기 대부분의 직원이 이미 대부분의 업무를 노트북과 모바일 디바이스로 처리하기 때문에 회사가 원격 근무에 완벽히 준비되어 있다고 생각할 수도 있다. 하지만 직원들이 ‘어디에서나 일할 수 있다’는 것과 실제로 모든 사람이 항상 원격지에서 근무하는 것은 다르다. 대면 상호작용이 비즈니스에서 차지하는 중요성을 과소평가하면 안 된다. 만일 회사가 코로나19에 대한 대응으로 직원들의 재택근무를 강력히 권장하는 경우, 직원의 상당수가 장기간 집에서 일할 수 있다. 데이터 보호 관점에서 보면 지적 재산이 데이터 센터 외부에서 생성될 가능성이 상당히 증가한다. 현재 회사가 데이터 저장에 파일 서버나 유사한 시스템에 의존하고 있는 경우, 원격으로 일하는 직원들은 이 시스템을 쉽게 사용할 수 없다. 그 결과 그들은 중요한 데이터를 노트북에서 바로 생성 및 저장하고, 중앙화된 회사 스토리지 사용은 안중에 없을 수 있다. 즉, 노트북 및 모바일 디바이스에서의 데이터 보호 정책을 검토해야 한다는 의미다. 대부분의 전문가가 강조하는 것과 달리, 많은 회사는 모바일 디바이스에 대한 백업이나 복구를 지원하지 않는데, 이것을 준비할 좋은 기회로 보인다. 노트북 백업에 실패하는 주된 이유는 시스템을 느리게 만들고 비용이 든다는 이유로 사용자들이 백업 프로세스를 삭제하기 때문이다. 다행인 점은 여러 제공업체가 사용자가 백업이 실행 중이라는 사실을 인식하지 못하는 방식으로 노트북과 모바일 디바이스에 대한 백업을 제공한다는 것이다. 모바일 디바이스 백업의 일반적인 대안은 오피스 365(Office 365...

재해복구 백업 코로나19 2020.03.04

사이버보안의 개념과 종류, 그리고 일자리

사이버보안(Cybersecurity)은 컴퓨터와 네트워크, 데이터를 악의적인 전자적 공격으로부터 보호하는 전반적인 활동이다. 실제 세상에서 건물이나 다른 사물에 대한 액세스를 제어하는 보다 전통적인 보안 활동인 물리적 보안과 비교가 되는 활동이다.   첨단 기술에 바탕을 둔 물리적 보안업체도 많고, 조직도에 물리적 보안과 사이버보안이 결합되어 있는 경우도 있지만, 사이버보안은 사유지 침입이나 절도가 아닌 악의적 로그인과 코드로부터 자산을 보호하는 것에 초점이 맞춰진 활동이다. 사이버보안의 종류 사이버보안은 여러 특정 분야의 활동을 포괄하는 광범위한 개념이다. 분류 방법은 많다. 예를 들어, 카스퍼스키 랩의 분류 체계가 있고, 마인드코어도 이런 체계를 갖고 있다. 하지만 다음과 같이 분류하는 경우가 가장 많다. - 네트워크 보안(Network security)은 승인되지 않은 상태에서 기업 네트워크를 침입하는 것을 막거나 방지하는 활동이다. - 애플리케이션 보안(Application security)은 애플리케이션 코드의 취약점을 찾아서 수정해 앱을 더 안전하게 만드는 보안 활동이다. - 데이터 보안으로도 부르는 정보 보안(Information security)은 저장 상태나 머신 간 전송 상태에서 승인되지 않은 액세스나 조작으로부터 데이터를 계속 안전하게 유지하는 활동이다. - OPSEC이라는 약자로 지칭되는 경우가 많은 운영 보안(Operational security)은 영리한 악의적 행위자가 적절히 분석을 하거나 다른 데이터와 결합하는 방법으로 숨겨야 할 ‘큰 그림’을 노출시킬 수 있는 퍼블릭 데이터를 평가, 보호하는 프로세스이다. - 재해 복구(disaster recovery)에도 사이버보안 활동으로 분류될 수 있는 요소들이 있다. 예를 들어, 사이버 공격으로 초래된 광범위한 데이터 손실이나 서비스 중지 상태를 바로잡아 복구하는 기법이 여기에 해당된다. 이런 사이버보안 활동들로 역시 특정한 개념을 갖고 있는 사이버보안 위협을 다룬다. 사...

재해복구 사이버보안 데이터보안 2019.12.10

윈도우 재해복구 툴킷을 만드는 방법

주말 내내 필자는 오작동하는 서버를 복구했다. 이 경험은 기업이 작든 크든 장애를 대비해 보안 재해 툴킷이 필요하다는 점을 다시 상기시켜 줬다. 또한, 복구를 원활하게 하기 위해 프로세스와 자원을 계획해둔 재해 체크리스트가 중요하다는 점도 다시 생각하게 됐다.   마이크로소프트용 툴 Sysmon으로 시작하는 툴킷에 대해 고려해 볼 만한 마이크로소프트에 맞는 좋은 툴이 있다. 마이크로소프트의 툴은 프로세스 생성, 네트워크 연결 및 파일 생성 시간 변경에 대한 자세한 정보를 제공한다. 이 툴은 재부팅 후와 재부팅 중에 시스템에 상주한다. 이쯤 되면 깃허브(Github)의 샘플 시스몬 구성을 검토해 보고 싶은 생각이 들 것이다. 그런 다음 (아직 하지 않았다면) 로컬 관리자 암호 툴킷으로 눈을 돌려보자. 보통 해커는 표적형 피싱 공격을 통해 네트워크에 접속한 후 로컬 관리자 암호의 해시를 얻기 위해 미미카츠(Mimikatz)나 wdigest 하베스팅과 같은 수단을 쓴다. 과거에는 관리자가 네트워크 전체에 같은 암호를 사용하는 경우가 많았다. 해커는 이러한 습관을 파악하고 탈취한 암호로부터 계속 확장해 네트워크에 완전한 접근권을 얻는다. 따라서 보안 사고가 발생하기 전에 당장 로컬 관리자 암호 툴킷을 설치하는 것이 좋다. 사고 후에 네트워크를 재구축하는 경우라면 이 툴킷을 사용해 더 안전한 방식으로 작업을 수행하고 손상된 암호를 통해 해커가 기업 시스템의 측면으로 이동할 수 있는 가능성을 줄일 수 있다. 꼭 설치해야 할 필요는 없지만 시스템에서 악성 파일을 찾아서 제거하는 마이크로소프트 세이프티 스캐너라는 툴도 있다. 최신 정의를 다운로드했는지 확실히 하려면 각 사고에 대해 해당 정의를 다운로드해야 한다. 세이프티 스캐너는 수동으로 구동된 경우에만 스캔하며 다운로드한 후 10일 동안 이용할 수 있다. 재해복구 꾸러미를 만들어라 종종 재해팀은 당장 사용할 수 있게 개인적이고 전문적인 주요 도구와 툴을 준비해둔 ‘꾸러미’를 가지고 있다. 이런 것이 있...

재해복구 보안 윈도우 2019.11.27

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.