2019.08.30

필요할 때 애저 백업이 작동하도록 보장하는 7단계 조치

Susan Bradley | CSO
최근 충격적인 랜섬웨어 공격이 미국 텍사스 주 22개 지방 정부를 덮쳐 세금 납부나 정상적인 업무처리를 수행할 수 없게 되었다. 이로 인해 공공단체와 민간단체 모두 이런 공격에서 회복할 수 있는 능력을 재검토할 필요가 있다는 점도 다시 한 번 일깨워주는 계기가 되었다. 이는 적절한 백업 전략을 갖는 것으로 시작한다.
 
ⓒ Getty Images Bank 

랜섬웨어 공격자들은 종종 네트워크가 어떻게 설정되고 기업이 백업 솔루션에 어떤 프로세스를 사용하는지 조사한다. 공격자는 먼저 백업 위치를 찾아 로컬 NAS 기기에서 조용하고 신속하게 백업을 삭제하고 1s와 0s로 장치에 기록해 큰 비용없이 백업을 완전히 삭제해 복구될 수 없도록 한다. 

공격자는 종종 온라인 백업을 먼저 타겟으로 삼는다. 공격자는 백업을 암호화하는 대신 백업이 있는 위치를 삭제하고 복구되지 않도록 그 위치 위에 무언가를 덮어 쓰려고 할 것이다. 그런 다음 가상화 게스트, 가상화 호스트, 워크스테이션 데이터, 마지막으로 도메인 컨트롤러를 대상으로 한다. 공격자는 서버 및 워크스테이션마다 서로 다른 암호키를 사용하고 모든 복구키에 대해 요금을 부과한다. 


애저에 대한 백업 및 랜섬웨어 복구의 모범 관행

핵심은 공격자들이 우리가 쉽게 해결하지 못하게 하는 것이다. 미국 국토안보부는 피해자가 취해야 할 조치에 대한 권고안을 내놓았다. 최고의 조치는 시스템을 백업하는 것이다. 이것조차도 오늘날의 비즈니스 경제에서는 까다로울 수 있다. 책임의 분열은 서로 다른 팀이 중요한 일을 처리한다고 생각하다가 결국 균열이 발생해 추락하는 상황을 초래할 수 있다. 백업이 설정되어 있지만 모니터링되지 않은 경우는 비일비재하다. 실제 백업이 동작하지 않을 때, 백업을 할 수 있다고 생각하는 것보다 더 나쁜 일은 없다. 

다음과 같은 7단계를 수행해 랜섬웨어 또는 기타 공격이 발생한 날, 백업이 이로부터 우리를 구원할 수 있도록 하자.

1. 경고 설정 방법을 검토하도록 한다. 백업이 실패할 때를 알려주는 알림을 설정하는 것 외에도 백업이 성공할 때의 알림도 고려하도록 한다. 백업 문제를 경고해야 하는 대체 수단을 알아본다. 백업 솔루션이 SMS 또는 기타 통신 수단을 통해 실패 알림을 전송하는 지를 검토해 실패가 더 명확하게 확인되도록 하라.

2. 백업 로그 파일이 있는 위치를 알고 비정상적인 문제가 있는지 정기적으로 검토하도록 한다. 애저의 경우 클라이언트에서 cloudbackup\operational 이벤트 로그를 검토할 수 있다. 애저 백업에 대한 메인 로그 파일들은 C:\program files\Microsoft Azure Recovery Services Agent\Temp이다. 다음의 로그도 검토하고자 할 것이다.

- C:\Program Files\Microsoft Azure Recovery Services Agent\Temp\CBEngineCurr.errlog
- C:\Program Files\Microsoft Azure Recovery Services Agent\Temp\CBUI0Curr.errlog
- C:\Program Files\Microsoft Azure Recovery Services Agent\Temp\CBCmdlet0Curr.errlog
 
마이크로소프트 애저 백업 로그  ⓒSusan Bradley

3. 백업에 대한 사용자 계정이 로그인되어 있지 않거나 로그인하지 않았었는지 항상 확인하라. 다른 인프라에서 액세스할 수 없는 대상을 완전히 별도의 네트워크에서 백업해야 하며, 백업 서버에서만 iSCSI 장치로 엄격하게 표시한다. 백업 소프트웨어에 로그인을 "개인화"할 수 있는 수단이 있는지 검토하고 별도의 사용자/허가 구조를 사용하도록 한다.

4. 스크립트 또는 기타 도구를 사용해 백업이 완료됐는지 확인한다. SQL 데이터베이스 백업이 마찬가지로 스크립트를 사용해 완료되고 있는지 다시 확인하도록 한다. 종종 간과되고 있는 백업이 가장 필요한 백업이 될 수 있다.

5. 구식의 종이 서류작성을 간과하지 않도록 한다. 사람들은 너무나 자주 공격자가 암호화할 수 있는 모든 네트워크 문서와 정보를 디지털 플랫폼에 둔다. 주요 문서를 인쇄하여 안전한 장소에 보관하도록 한다.
 
6. 다른 이메일 플랫폼에 등록해 팀원과 통신할 수 있도록 하는 등 대체 통신 방법을 계획했는지 확인하도록 한다.

7. 마지막으로, 전체 네트워크를 처음부터 복원할 수 있다는 것을 명심하면서 항상 정기적으로 백업 복구를 테스트한다. 자신에게 최악의 일이 생기면 어떻게 할 것인지 생각해 보라. 준비가 되어 있는가? 만약이 아니라 언제든지 일어날 수 있다는 가정 하에 계획을 세워둬야 한다. editor@itworld.co.kr


2019.08.30

필요할 때 애저 백업이 작동하도록 보장하는 7단계 조치

Susan Bradley | CSO
최근 충격적인 랜섬웨어 공격이 미국 텍사스 주 22개 지방 정부를 덮쳐 세금 납부나 정상적인 업무처리를 수행할 수 없게 되었다. 이로 인해 공공단체와 민간단체 모두 이런 공격에서 회복할 수 있는 능력을 재검토할 필요가 있다는 점도 다시 한 번 일깨워주는 계기가 되었다. 이는 적절한 백업 전략을 갖는 것으로 시작한다.
 
ⓒ Getty Images Bank 

랜섬웨어 공격자들은 종종 네트워크가 어떻게 설정되고 기업이 백업 솔루션에 어떤 프로세스를 사용하는지 조사한다. 공격자는 먼저 백업 위치를 찾아 로컬 NAS 기기에서 조용하고 신속하게 백업을 삭제하고 1s와 0s로 장치에 기록해 큰 비용없이 백업을 완전히 삭제해 복구될 수 없도록 한다. 

공격자는 종종 온라인 백업을 먼저 타겟으로 삼는다. 공격자는 백업을 암호화하는 대신 백업이 있는 위치를 삭제하고 복구되지 않도록 그 위치 위에 무언가를 덮어 쓰려고 할 것이다. 그런 다음 가상화 게스트, 가상화 호스트, 워크스테이션 데이터, 마지막으로 도메인 컨트롤러를 대상으로 한다. 공격자는 서버 및 워크스테이션마다 서로 다른 암호키를 사용하고 모든 복구키에 대해 요금을 부과한다. 


애저에 대한 백업 및 랜섬웨어 복구의 모범 관행

핵심은 공격자들이 우리가 쉽게 해결하지 못하게 하는 것이다. 미국 국토안보부는 피해자가 취해야 할 조치에 대한 권고안을 내놓았다. 최고의 조치는 시스템을 백업하는 것이다. 이것조차도 오늘날의 비즈니스 경제에서는 까다로울 수 있다. 책임의 분열은 서로 다른 팀이 중요한 일을 처리한다고 생각하다가 결국 균열이 발생해 추락하는 상황을 초래할 수 있다. 백업이 설정되어 있지만 모니터링되지 않은 경우는 비일비재하다. 실제 백업이 동작하지 않을 때, 백업을 할 수 있다고 생각하는 것보다 더 나쁜 일은 없다. 

다음과 같은 7단계를 수행해 랜섬웨어 또는 기타 공격이 발생한 날, 백업이 이로부터 우리를 구원할 수 있도록 하자.

1. 경고 설정 방법을 검토하도록 한다. 백업이 실패할 때를 알려주는 알림을 설정하는 것 외에도 백업이 성공할 때의 알림도 고려하도록 한다. 백업 문제를 경고해야 하는 대체 수단을 알아본다. 백업 솔루션이 SMS 또는 기타 통신 수단을 통해 실패 알림을 전송하는 지를 검토해 실패가 더 명확하게 확인되도록 하라.

2. 백업 로그 파일이 있는 위치를 알고 비정상적인 문제가 있는지 정기적으로 검토하도록 한다. 애저의 경우 클라이언트에서 cloudbackup\operational 이벤트 로그를 검토할 수 있다. 애저 백업에 대한 메인 로그 파일들은 C:\program files\Microsoft Azure Recovery Services Agent\Temp이다. 다음의 로그도 검토하고자 할 것이다.

- C:\Program Files\Microsoft Azure Recovery Services Agent\Temp\CBEngineCurr.errlog
- C:\Program Files\Microsoft Azure Recovery Services Agent\Temp\CBUI0Curr.errlog
- C:\Program Files\Microsoft Azure Recovery Services Agent\Temp\CBCmdlet0Curr.errlog
 
마이크로소프트 애저 백업 로그  ⓒSusan Bradley

3. 백업에 대한 사용자 계정이 로그인되어 있지 않거나 로그인하지 않았었는지 항상 확인하라. 다른 인프라에서 액세스할 수 없는 대상을 완전히 별도의 네트워크에서 백업해야 하며, 백업 서버에서만 iSCSI 장치로 엄격하게 표시한다. 백업 소프트웨어에 로그인을 "개인화"할 수 있는 수단이 있는지 검토하고 별도의 사용자/허가 구조를 사용하도록 한다.

4. 스크립트 또는 기타 도구를 사용해 백업이 완료됐는지 확인한다. SQL 데이터베이스 백업이 마찬가지로 스크립트를 사용해 완료되고 있는지 다시 확인하도록 한다. 종종 간과되고 있는 백업이 가장 필요한 백업이 될 수 있다.

5. 구식의 종이 서류작성을 간과하지 않도록 한다. 사람들은 너무나 자주 공격자가 암호화할 수 있는 모든 네트워크 문서와 정보를 디지털 플랫폼에 둔다. 주요 문서를 인쇄하여 안전한 장소에 보관하도록 한다.
 
6. 다른 이메일 플랫폼에 등록해 팀원과 통신할 수 있도록 하는 등 대체 통신 방법을 계획했는지 확인하도록 한다.

7. 마지막으로, 전체 네트워크를 처음부터 복원할 수 있다는 것을 명심하면서 항상 정기적으로 백업 복구를 테스트한다. 자신에게 최악의 일이 생기면 어떻게 할 것인지 생각해 보라. 준비가 되어 있는가? 만약이 아니라 언제든지 일어날 수 있다는 가정 하에 계획을 세워둬야 한다. editor@itworld.co.kr


X