BLOG
이번 포스팅에서는Amazon Web Services(AWS) 고객이 랜섬웨어로부터 리소스를 보호하고 복구하기 위해 수행할 수 있는 5가지의 조치 사항을 알려드리고자 합니다. 이 5가지 조치는 여러분이 취해야 하는 선제적 조치에 중점을 두었습니다.
#1- 앱 및 데이터 복구 기능 설정
기존의 encrypt-in-place 랜섬웨어 시도가 성공하려면 랜섬웨어 공격을 시도하는 자가 사용자의 데이터 액세스를 차단한 다음 몸값(ransom)을 요구하기 위해 데이터를 차지해야 합니다. 이 경우 사용자가 계정을 보호하기 위해서 가장 먼저 해야 할 일은 어떻게 데이터에 액세스할 수 없게 되었는지와는 관계없이 데이터를 복구할 수 있는지 확인하는 것입니다. 백업 솔루션은 데이터를 보호 및 복원하고, 재해 복구(DR) 솔루션은 데이터 및 워크로드의 빠른 복구를 제공합니다. AWS는 강력한 인프라 DR을 제공하는 AWS Backup 또는 CloudEndure Disaster Recovery 와 같은 서비스를 사용하여 이 프로세스를 훨씬 더 쉽게 만들었습니다. 이번 포스팅에서는 이 두 서비스를 모두 사용하여 데이터를 복구하는 방법에 대해 설명하겠습니다.
데이터 백업 솔루션을 선택할 때 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스의 스냅샷을 생성하는 것만으로는 충분하지 않습니다. AWS Backup 서비스의 강력한 기능은 백업 볼트를 생성할 때 AWS Key Management Service(AWS KMS) 에서 다른 고객 마스터 키(CMK) 를 사용할 수 있다는 것입니다. 이는 CMK가 AWS 운영자가 키를 사용하여 백업을 암호화하도록 허용하는 키 정책을 가질 수 있기 때문에 강력하지만 사용자는 완전히 다른 보안 주체로 복호화를 제한할 수 있습니다. 그림 1에서는 CMK A를 사용하여 EC2 Amazon Elastic Block Store(Amazon EBS) 볼륨을 로컬로 암호화한 계정을 보여주지만, AWS Backup은 CMK B를 사용합니다. CMK A에 대한 암호 해독 권한이 있는 계정 A의 사용자가 액세스를 시도하는 경우 사용자가 AWS Identity and Access Management(IAM) 보안 주체 액세스 정책의 승인을 받더라도 CMK 정책은 암호화된 데이터에 대한 액세스를 허용하지 않습니다.
그림 1: 키 구성 요소가 다른 별도의 계정에 데이터를 저장하는 AWS Backup을 사용하는 계정
백업 또는 복제를 백업 전용인 별도의 계정에 배치하면 위협 행위자가 백업을 파괴하거나 변조할 가능성을 줄이는 데 도움이 됩니다. 이제 AWS Backup은 이 교차 계정 기능을 기본적으로 지원하므로 백업 프로세스가 훨씬 쉬워집니다. AWS Backup 개발자 안내서는 이 기능을 사용하기 위한 지침과 적용해야 하는 정책을 제공하고 있습니다. 이때 지원되는 모든 서비스에서 데이터를 백업하고 있고 백업 일정이 비즈니스 RTO(복구 시간 목표) 및 RPO(복구 시점 목표)를 기반으로 하는지 확인해야 합니다. 이제 CloudEndure Disaster Recovery가 작동하는 방식을 살펴보겠습니다.
그림 2: CloudEndure Disaster Recovery 작동 방식 개요
그림 2의 high-level architecture 다이어그램은 CloudEndure Disaster Recovery가 어떻게 전체 온프레미스 환경을 AWS의 복제본과 동기화하고 공격적인 복구 목표와 총 소유 비용(TCO)의 대폭적인 절감으로 언제든지 AWS로 fail over할 수 있도록 지원하는 방법을 보여줍니다. 왼쪽 그림은 다양한 유형의 애플리케이션으로 구성될 수 있는 소스 환경을 나타냅니다. 이 경우 Oracle 데이터베이스와 SQL Server를 예로 들어 설명하겠습니다. 이 예에서는 온프레미스에서 AWS로의 DR을 강조하고 있지만 CloudEndure Disaster Recovery는 이미 AWS에 있는 워크로드에 대해 AWS 리전 간에 동일한 기능과 향상된 복구 성능을 제공할 수 있습니다.
CloudEndure 에이전트는 어떤 종류의 재부팅도 요구하지 않으면서 성능에 영향을 미치지 않고 소스 시스템에 배포됩니다. 그러면 해당 데이터를 AWS로 거의 지속적으로 복제하기 시작합니다. CloudEndure Disaster Recovery는 또한 복제 중 그리고 장애 조치 또는 재해 복구 테스트 중에 해당 머신이 실제로 회전해야 할 때까지 클라우드 인프라 비용을 줄이는 데 도움이 되는 저비용 스테이징 영역을 프로비저닝합니다. 고객에게 중단이 발생하면 CloudEndure Disaster Recovery가 적절한 AWS 리전 VPC 및 선택한 대상 서브넷에서 머신을 시작합니다. 준비 영역이라고 하는 휴면 경량 상태는 이제 소스 환경(이 경우 Oracle 데이터베이스 및 SQL Server)에서 마이그레이션된 실제 서버로 시작됩니다. CloudEndure Disaster Recovery의 기능 중 하나는 랜섬웨어 이벤트 발생 시 중요한 지정 시간 복구입니다. 이 기능을 사용하여 선택한 이전의 일관된 시점으로 환경을 복구할 수 있기 때문입니다. 즉, 이벤트 이전의 환경으로 돌아갈 수 있습니다.
CloudEndure Disaster Recovery의 시스템 변환 기술은 복제된 시스템이 AWS 내에서 기본적으로 실행될 수 있으며 일반적으로 시스템이 부팅되는 데 몇 분 정도 걸립니다. 또한 복제 또는 사용자 활동에 영향을 주지 않고 자주 DR 준비 테스트를 수행할 수 있습니다. 데이터 보호에 유용한 또 다른 서비스는 AWS 객체 스토리지 서비스인 Amazon Simple Storage Service(Amazon S3)인데요, 여기서는 개체가 랜섬웨어 암호화 파일로 덮어 씌워지는 것을 방지하는 object versioning 이나, 개체가 수정되거나 덮어 씌워지는 것을 방지하는 WORM(Write Once, Read Many) 솔루션과 같은 기능들을 사용할 수 있습니다.
DR 계획 및 비즈니스 연속성 계획 개발에 대한 자세한 내용은 다음 페이지를 참조하십시오.
- 백업 및 재해 복구
- 재해 복구 계획 (AWS Well-Architected 프레임워크에서)
#2 – 데이터 암호화
몸값(ransom)을 위해 데이터를 보유하는 것 외에도 최근의 랜섬웨어 이벤트는 이중 갈취 수법을 점점 더 많이 사용합니다. 이중 갈취는 행위자가 데이터를 암호화할 뿐만 아니라 데이터를 유출하고 몸값을 지불하지 않으면 데이터를 공개하겠다고 위협하는 경우입니다. 데이터를 보호하려면 항상 데이터 암호화를 활성화하고 워크플로를 분할하여 권한 있는 시스템과 사용자가 키 자료를 사용하여 데이터를 해독할 수 있는 권한을 제한해야 합니다. 예를 들어, API를 사용하여 데이터 객체를 S3 버킷에 쓰는 웹 애플리케이션이 있다고 가정해 보겠습니다. 이 경우 애플리케이션에 전체 읽기 및 쓰기 권한을 부여하는 대신 애플리케이션을 단일 작업(예: PutObject )으로 제한하는 것이 좋습니다. 코드가 작고, 재사용이 가능할수록 관리하기도 더 쉽기 때문에 워크플로를 세분화하면 개발자가 더 빠르게 작업할 수 있습니다. 읽기 작업과 쓰기 작업에 별도의 CMK 정책을 사용하여 액세스를 제한하는 이러한 유형의 워크플로의 예가 그림 3에 나와 있습니다.
그림 3: 읽기 작업과 쓰기 작업에 별도의 CMK 정책을 사용하는 서버리스 워크플로
AWS 관리형 CMK 가 저장 데이터 암호화에 대한 규제 요구 사항을 충족하는 데 도움이 될 수 있지만, 고객 키 정책은 지원하지 않는다는 점에 유의해야 합니다. 따라서 키 구성 요소가 사용되는 방식을 제어하려는 고객은 고객 관리형 CMK를 사용해야 합니다. Amazon EBS 에 로컬로 저장된 데이터의 경우 블록은 AWS KMS 를 사용하여 암호화되지만 서버 부팅 후 데이터는 운영 체제 수준에서 로컬로 암호화가 해제됩니다. 애플리케이션의 일부로 로컬에 저장되는 민감한 데이터가 있는 경우 AWS Encryption SDK 또는 Encryption CLI 와 같은 도구를 사용하여 해당 데이터를 암호화된 형식으로 저장하는 것을 고려하는 것이 좋습니다. Amazon CTO Werner Vogels가 말했듯이 모든 것을 암호화하는 것이 가장 중요합니다!
그림 4: Amazon CTO Werner Vogels는 고객이 모든 것을 암호화하기를 원합니다.
#3 – 중요한 패치 적용
액터가 시스템에 액세스하려면 취약점이나 잘못된 구성을 이용해야 합니다. 많은 조직이 인프라에 패치를 적용하지만 일부는 매주 또는 매월만 수행하므로 연중무휴 운영이 필요한 중요한 시스템에 패치를 적용하는 데는 충분하지 않을 수 있습니다. 점점 더 많은 위협 행위자가 패치 또는 CVE(공통 취약점 노출) 발표를 몇 시간 내에 리버스 엔지니어링할 수 있는 능력을 갖게 되었습니다. 보안 관련 패치, 특히 심각도가 높은 패치를 가능한 한 최소한의 지연으로 배포해야 합니다. AWS Systems Manager 를 사용하면 클라우드 및 온프레미스에서 이 프로세스를 자동화할 수 있습니다. Systems Manager 패치 기준선 을 사용하면 머신 태그(예: 개발 대 프로덕션)를 기반으로 패치를 적용할 수 있지만 패치 유형을 기반으로 할 수도 있습니다.
예를 들어 사전 정의된 패치 기준 AWS-AmazonLinuxDefaultPatchBaseline 은 ‘보안’으로 분류되고 심각도 수준이 ‘Critical’ 또는 ‘Important’인 모든 운영 체제 패치를 승인합니다. 패치는 릴리스 후 7일이 지나면 자동으로 승인됩니다. 기준선은 또한 릴리스 7일 후에 ‘버그 수정’으로 분류된 모든 패치를 자동 승인합니다. 보다 적극적인 패칭 포지션을 원하는 경우 사용자 지정 기준선을 대신 생성할 수 있습니다. 예를 들어 그림 5에서는 심각도가 심각한 모든 Windows 버전에 대한 기준선을 만들었습니다.
그림 5: Systems Manager용 맞춤형 패치 기준 생성의 예
그런 다음 이 기준을 기반으로 플릿 및 패치 전체 또는 일부를 스캔하도록 시간별 예약 이벤트를 설정할 수 있습니다. 그림 6에서는 패치 기준 프로세스에 대한 개요를 제공하고 클라우드 환경에서 이를 사용하는 방법을 설명하는 이 AWS 블로그 게시물 에서 가져온 이러한 유형의 워크플로의 예를 보여줍니다.
그림 6: Systems Manager를 사용하여 스캔, 확인, 패치 및 보고하는 방법을 보여주는 예제 워크플로
또한 AWS Organizations를 사용하는 경우 이 블로그 게시물 은 해당 방법을 조직 전체에 적용하는 방법을 보여줍니다. AWS는 패치를 더 쉽게 할 수 있는 많은 도구를 제공하며, 서버가 완전히 패치되었는지 확인하면 랜섬웨어에 대한 취약성을 크게 줄일 수 있습니다.
#4 – 보안 표준 준수
여러분의 환경이 안전한지 섣불리 판단하는 것은 위험합니다. 대부분의 상업 및 공공 부문 고객은 일정 형태의 규정 또는 규정 준수 표준의 적용을 받지만, 지속적인 관행에서 인정된 표준에 대해 보안 및 위험 상태를 측정해야 합니다. 따라야 할 프레임워크가 없는 경우에는 AWS Well-Architected 프레임워크 를 기준으로 사용하는 것이 좋습니다. AWS Security Hub를 사용하면 AWS 보안 서비스와 타사 툴의 데이터를 단일 뷰로 볼 수 있으며, CIS AWS Foundations Benchmark, Payment Card Industry Data Security Standard (PCI DSS), AWS Foundational Security Best Practices와 같은 표준 또는 프레임워크를 기준으로 계정을 벤치마킹할 수도 있습니다. 이는 규정 준수 편차가 발생할 때 경고할 수 있는 환경의 자동화된 스캔입니다.
또한, AWS Config 적합성 팩 을 사용하여 NIST 800-53, HIPAA(Health Insurance Portability and Accountability Act)에 대한 제어 하위 집합을 자동화 하도록 선택할 수 있습니다. 한국– ISMS(정보 보안 관리 시스템) 이 발행한 60개 이상의 적합성 팩 템플릿 목록이 지금 이 순간에도 증가하고 있습니다. 모범 사례를 따를 때, 또 다른 중요한 측면은 모든 수준에서 최소 권한을 구현하는 것입니다. AWS에서는 IAM 을 사용하여 최소 권한을 적용하는 정책을 작성할 수 있습니다. 이러한 정책은 역할을 통해 적용될 때 사용자 환경에서 발전할 수 있는 행위자의 능력을 제한합니다. Access Analyzer 는 최소 권한을 보다 쉽게 생성할 수 있는 IAM의 새로운 기능이며 이 블로그 게시물 에서도 다루고 있습니다.
#5– 응답 모니터링 및 자동화
강력한 모니터링 및 경고가 준비되어 있는지 확인하십시오. 앞에서 설명한 각 항목은 랜섬웨어 이벤트로부터 보호하는 데 도움이 되는 강력한 도구이지만 가정을 검증하기 위한 강력한 모니터링이 없으면 아무 것도 작동하지 않습니다. 여기서는 이 게시물 앞부분의 예를 기반으로 몇 가지 구체적인 예를 제공하고자 합니다.
#1(앱 및 데이터 복구 기능 설정)에 설명된 대로 AWS Backup 을 사용하여 데이터를 백업하는 경우, 백업 작업이 실패할 때 알림을 보내도록 Amazon CloudWatch를 설정해야 합니다 . 경고가 트리거되면 이에 대한 조치도 수행해야 합니다. AWS 알림 이메일에 대한 응답이 작업을 다시 실행하는 것이라면 AWS Lambda를 사용하여 해당 워크플로를 자동화해야 합니다. 후속 실패가 발생하면 티켓 서비스에서 티켓을 자동으로 열거나 운영 팀에 호출하십시오.
#2(데이터 암호화)에 설명된 대로 모든 데이터를 암호화하는 경우 AWS KMS 가 작업에 대한 권한을 거부하는 시점을 확인하기 위해 AWS CloudTrail 을 보고 계시나요?
또한, #3(중요한 패치 적용)에 설명된 대로 패치 관리 기준선을 모니터링하고 조치를 취하고 패치를 성공적으로 배포할 수 없을 때 대응하고 계신가요?
마지막으로, Security Hub 규정 준수 보고서의 규정 준수 상태를 관찰하고 발견사항에 대한 조치를 취하고 있습니까? 또한 의심스러운 활동이 있는지 환경을 모니터링하고 위험을 완화하기 위해 신속하게 조사하고 조치를 취해야 합니다. 이러한 사항들을 준수할 때 아마존 GuardDuty, 보안 허브 및 Amazon Detective가 여러분께 도움이 될 수 있습니다.
AWS를 사용하면 앞서 언급한 알림에 대한 자동화된 응답을 더 쉽게 생성할 수 있습니다. 이 블로그 게시물 의 다중 계정 응답 솔루션은 워크로드 요구 사항에 따라 응답을 사용자 지정하는 데 사용할 수 있는 좋은 출발점을 제공합니다.
결론
이번 포스팅에서는 랜섬웨어 이벤트를 보호하고 복구하기 위해 취할 수 있는 5가지 조치를 소개해 드렸는데요, 오늘 알려 드린 선제적 조치 사항 외에도 NIST는 최근 NIST SP1800-25 간행물에서 볼 수 있는 랜섬웨어 예방에 대한 지침을 게시했습니다.
더 많은 AWS 보안 방법 콘텐츠, 뉴스 및 기능 발표를 원하신다면 Twitter에서 저희를 팔로우해 보세요!
메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글이나 관련 기사 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.