# AWS Security Incident Response 기술 지침
**Topics**
+ [요약](#abstract)
+ [귀사는 Well-Architected입니까?](#are-you-well-architected)
+ [소개](introduction.md)
+ [준비](preparation.md)
+ [운영](operations.md)
+ [인시던트 사후 활동](post-incident-activity.md)
+ [결론](conclusion.md)
+ [기여자](contributors.md)
+ [부록 A: 클라우드 기능 정의](appendix-a-cloud-capability-definitions.md)
+ [부록 B: AWS 인시던트 대응 리소스](appendix-b-incident-response-resources.md)
+ [Notices](notices.md)
## 요약
이 가이드에서는 고객의 Amazon Web Services(AWS) 클라우드 환경 내 보안 인시던트 대응의 기본 사항에 대한 개요를 제공합니다. 클라우드 보안 및 인시던트 대응 개념의 개요를 제공하고 보안 문제에 대응하는 고객이 사용할 수 있는 클라우드 기능, 서비스 및 메커니즘을 파악합니다.
이 가이드는 기술 담당자를 대상으로 하며, 정보 보안의 일반 원칙을 잘 알고 있고, 현재 온프레미스 환경 내 보안 인시던트 대응에 대한 기본적인 이해가 있으며, 클라우드 서비스에 어느 정도 익숙하다는 가정하에 작성되었습니다.
## 귀사는 Well-Architected입니까?
[AWS Well-Architected 프레임워크](https://aws.amazon.com/architecture/well-architected/)는 클라우드에서 시스템을 구축할 때 내리는 결정의 장단점을 이해하는 데 도움이 됩니다. 이 프레임워크를 사용하여 클라우드에서 안정적이고 안전하며 효율적이고 비용 효율적인 시스템을 설계하고 운영하기 위한 아키텍처 모범 사례를 살펴볼 수 있습니다. [AWS Well-Architected Tool 콘솔](https://console.aws.amazon.com/wellarchitected)에서 무료로 제공되는 [AWS Well-Architected Tool](https://aws.amazon.com/well-architected-tool/) 사용하면 각 요소에 대한 일련의 질문에 답하여, 이러한 모범 사례와 비교하여 워크로드를 검토할 수 있습니다.
참조 아키텍처 배포, 다이어그램, 백서 등 클라우드 아키텍처에 대한 더 많은 전문가 지침과 모범 사례를 보려면 [AWS 아키텍처 센터](https://aws.amazon.com/architecture/)를 참조하세요.
# 소개
AWS는 보안을 최우선으로 생각합니다. AWS 고객은 보안에 가장 민감한 조직의 요구를 지원하도록 구축된 데이터 센터와 네트워크 아키텍처의 이점을 누릴 수 있습니다. AWS는 공동 책임 모델을 채택하고 있습니다. 즉, AWS가 클라우드*의* 보안을 관리하고, 고객이 클라우드 *내* 보안을 책임집니다. 이는 보안 목표 달성에 도움이 되는 다양한 도구와 서비스에 대한 액세스를 포함하여 보안 구현을 완벽하게 제어할 수 있음을 의미합니다. 이러한 기능은 AWS 클라우드에서 실행되는 애플리케이션의 보안 기준을 설정하는 데 도움이 됩니다.
잘못된 구성이나 외부 요인 변경 등으로 인해 기준에서 벗어나는 경우 대응하고 조사해야 합니다. 이를 성공적으로 수행하려면 AWS 환경 내 보안 인시던트 대응의 기본 개념과 보안 문제가 발생하기 전에 클라우드 팀을 준비, 교육 및 훈련하기 위한 요구 사항을 파악해야 합니다. 사용할 수 있는 제어와 기능을 파악하고, 잠재적 문제를 해결하기 위한 주제 예시를 검토하고, 자동화를 사용하여 대응 속도와 일관성을 개선하는 해결 방법을 식별하는 것이 중요합니다. 또한 이러한 요구 사항을 충족하기 위해 보안 인시던트 대응 프로그램 구축과 관련된 규정 준수 및 규제 요구 사항을 이해해야 합니다.
보안 인시던트 대응은 복잡할 수 있으므로 핵심 보안 서비스부터 시작하여 기본 탐지 및 대응 기능을 구축한 다음 플레이북을 개발하여 반복 및 개선을 위한 인시던트 대응 메커니즘의 초기 라이브러리를 생성하는 등 반복적인 접근 방식을 구현하는 것이 좋습니다.
## 시작하기 전에
AWS에서 보안 이벤트에 대한 인시던트 대응에 대해 알아보기 전에 AWS 보안 및 인시던트 대응을 위한 관련 표준 및 프레임워크를 숙지하세요. 이러한 기반은 이 가이드에 제시된 개념과 모범 사례를 이해하는 데 도움이 됩니다.
### AWS 보안 표준 및 프레임워크
먼저 [보안, 자격 증명 및 규정 준수 모범 사례, 보안 요소 - AWS Well-Architected Framework](https://aws.amazon.com/architecture/security-identity-compliance/) 및 [보안 관점: AWS Cloud Adoption Framework(AWS CAF)의 개요](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/security-perspective.html) 백서를 검토하는 것이 좋습니다.
AWS CAF는 클라우드로 전환하는 조직의 여러 부서 간 조정을 지원하는 지침을 제공합니다. AWS 클라우드 기반 IT 시스템 구축과 관련된 몇 가지 중점 영역(관점)으로 나뉩니다. 보안 관점에서는 워크스트림 전반에서 보안 프로그램을 구현하는 방법을 설명하며, 그 중 하나가 인시던트 대응입니다. 이 문서는 고객이 효과적이고 효율적인 보안 인시던트 대응 프로그램과 역량을 구축할 수 있도록 지원하기 위해 고객과 협력한 경험의 산물입니다.
### 산업 인시던트 대응 표준 및 프레임워크
이 백서는 NIST(국립표준기술연구소)에서 만든 [Computer Security Incident Handling Guide SP 800-61 r3](https://csrc.nist.gov/pubs/sp/800/61/r3/final)의 인시던트 대응 표준 및 모범 사례를 따릅니다. NIST에서 소개하는 개념을 읽고 이해하는 것은 유용한 전제 조건입니다. 이 NIST 가이드의 개념과 모범 사례는 이 백서의 AWS 기술에 적용됩니다. 그러나 온프레미스 인시던트 시나리오는 이 가이드의 범위를 벗어납니다.
## AWS 인시던트 대응 개요
먼저 클라우드에서 보안 운영과 인시던트 대응이 어떻게 다른지 이해하는 것이 중요합니다. AWS에서 효과적인 대응 기능을 구축하려면 기존 온프레미스 대응과의 편차와 이러한 편차가 인시던트 대응 프로그램에 미치는 영향을 이해해야 합니다. 이러한 각 차이점과 핵심 AWS 인시던트 대응 설계 원칙은 이 섹션에 자세히 설명되어 있습니다.
### AWS 인시던트 대응 측면
조직 내 모든 AWS 사용자는 보안 인시던트 대응 프로세스에 대한 기본적인 이해가 있어야 하며 보안 직원은 보안 문제에 대응하는 방법을 이해해야 합니다. 교육, 훈련 및 경험은 성공적인 클라우드 인시던트 대응 프로그램에 필수적이며 발생 가능한 보안 인시던트를 처리하기 전에 미리 구현하는 것이 이상적입니다. 클라우드에서의 성공적인 인시던트 대응 프로그램은 *준비*, *운영*, *인시던트 사후 활동*에 기반합니다.
이러한 각 측면을 이해하려면 다음 설명을 고려하세요.
+ **준비** - 탐지 제어를 활성화하고 필요한 도구 및 클라우드 서비스에 대한 적절한 액세스를 확인하여 인시던트 대응 팀이 AWS 내부 인시던트를 탐지하고 이에 대응할 수 있도록 준비합니다. 또한 신뢰할 수 있는 일관된 응답을 보장하는 데 필요한 수동 및 자동 런북을 준비합니다.
+ **운영** - 탐지, 분석, 방지, 근절 및 복구와 같은 NIST의 인시던트 대응 단계에 따라 보안 이벤트 및 잠재적 인시던트를 해결합니다.
+ **인시던트 사후 활동** - 보안 이벤트 및 시뮬레이션의 결과를 반복하여 대응의 효율성을 높이고, 대응 및 조사를 통해 도출된 가치를 높이며, 위험을 더욱 줄입니다. 인시던트를 통해 배우고 개선 활동에 대한 강한 주인의식을 가져야 합니다.
이 가이드에서 이러한 각 측면을 살펴보고 자세히 설명합니다. 다음 다이어그램에서는 이러한 측면의 흐름을 보여줍니다. 흐름은 앞서 언급한 NIST 인시던트 대응 수명 주기와 일치하지만 탐지 및 분석, 방지, 근절 및 복구를 포함하는 작업을 수행합니다.
![\[AWS 인시던트 대응의 측면을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/images/aspects-of-incident-response.png)
### AWS 인시던트 대응 원칙 및 설계 목표
[NIST SP 800-61 Computer Security Incident Handling Guide](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final)에 정의된 일반적인 인시던트 대응 프로세스와 메커니즘은 타당하지만, 클라우드 환경에서 보안 인시던트에 대응하는 것과 관련된 구체적인 설계 목표를 고려하는 것이 좋습니다.
+ **대응 목표 수립** - 이해관계자, 법률 자문, 조직 리더십과 협력하여 인시던트 대응 목표를 결정합니다. 몇 가지 공통 목표로, 문제 격리 및 완화, 영향을 받는 리소스 복구, 포렌식을 위한 데이터 보존, 알려진 안전한 운영 환경으로 복구, 궁극적으로 인시던트를 통한 학습 등이 포함됩니다.
+ **클라우드를 사용하여 대응** - 이벤트와 데이터가 존재하는 곳에 대응 패턴을 구현합니다.
+ **무엇을 가지고 있고 무엇이 필요한지 파악** - 로그, 리소스, 스냅샷 및 기타 증거를 대응 전용 중앙 집중식 클라우드 계정에 복사 및 저장하여 보존합니다. 태그, 메타데이터, 보존 정책을 적용하는 메커니즘을 사용합니다. 어떤 서비스를 사용하고 있는지 파악한 다음 해당 서비스를 조사하기 위한 요구 사항을 파악해야 합니다. 환경을 이해하는 데 도움이 되도록 이 문서 뒷부분의 [태그 지정 전략 개발 및 구현](develop-and-implement-tagging-strategy.md) 섹션에서 다루는 태깅을 사용할 수도 있습니다.
+ **재배포 메커니즘 사용:** 잘못된 구성으로 인해 보안 이상이 발생한 경우 올바른 구성으로 리소스를 재배포하여 변형을 제거하는 것만으로 간단하게 문제를 해결할 수 있습니다. 손상 가능성이 확인되면 재배포에 성공적이고 검증된 근본 원인 완화 조치가 포함되어 있는지 확인하세요.
+ **가능한 경우 자동화** - 문제가 발생하거나 인시던트가 반복되면 프로그래밍 방식으로 분류하고 일반적인 이벤트에 대응하는 메커니즘을 구축하세요. 자동화가 불가능한 고유하거나 복잡하거나 민감한 인시던트에는 사람의 대응을 활용하세요.
+ **확장 가능한 솔루션 선택** - 클라우드 컴퓨팅에 대한 조직의 접근 방식의 확장성과 일치하도록 노력하세요. 환경 전반으로 규모가 조정되는 탐지 및 대응 메커니즘을 구현하여 탐지와 대응 사이의 시간을 효과적으로 줄이세요.
+ **프로세스 교육 및 개선** - 프로세스, 도구 또는 인력의 격차를 사전에 파악하고 이를 해결하기 위한 계획을 실행하세요. 시뮬레이션은 격차를 찾고 프로세스를 개선할 수 있는 안전한 방법입니다. 프로세스를 반복하는 방법에 대한 자세한 내용은 이 문서의 [인시던트 사후 활동](post-incident-activity.md) 섹션을 참조하세요.
이러한 설계 목표는 인시던트 대응과 위협 탐지를 모두 수행할 수 있는지 아키텍처 구현을 검토하도록 상기시켜줍니다. 클라우드 구현을 계획할 때는 포렌식에 기반하여 타당한 대응 방법론을 사용하여 인시던트에 대응하는 방안을 생각해 보세요. 경우에 따라 이러한 대응 태스크를 위해 특별히 설정된 조직, 계정 및 도구가 여러 개 있을 수 있습니다. 이러한 도구와 기능은 배포 파이프라인을 통해 인시던트 대응 담당자가 사용할 수 있도록 해야 합니다. 더 큰 위험을 초래할 수 있으므로 정적이어서는 안 됩니다.
### 클라우드 보안 인시던트 영역
AWS 환경에서 보안 이벤트에 효과적으로 대비하고 대응하려면 일반적인 클라우드 보안 인시던트 유형을 이해해야 합니다. 고객의 책임하에 보안 인시던트가 발생할 수 있는 세 가지 영역은 서비스, 인프라, 애플리케이션입니다. 영역마다 다른 지식, 도구 및 대응 프로세스가 필요합니다. 다음 영역을 고려하세요.
+ **서비스 영역** - 서비스 영역의 인시던트는 AWS 계정, [AWS Identity and Access Management](https://aws.amazon.com/iam/)(IAM) 권한, 리소스 메타데이터, 결제 또는 기타 영역에 영향을 줄 수 있습니다. 서비스 영역 이벤트는 AWS API 메커니즘으로만 대응하거나 구성 또는 리소스 권한과 관련된 근본 원인이 있는 이벤트이며 관련 서비스 지향 로깅이 있을 수 있습니다.
+ **인프라 영역** - 인프라 영역의 인시던트에는 [Amazon Elastic Compute Cloud](https://aws.amazon.com/ec2/)(Amazon EC2) 인스턴스의 프로세스 및 데이터, 가상 프라이빗 클라우드(VPC) 내의 Amazon EC2 인스턴스로의 트래픽, 컨테이너 또는 기타 향후 서비스와 같은 기타 영역 등의 데이터 또는 네트워크 관련 활동이 포함됩니다. 인프라 영역 이벤트에 대한 대응에는 포렌식 분석을 위한 인시던트 관련 데이터 획득이 포함되는 경우가 많습니다. 여기에는 인스턴스 운영 체제와의 상호 작용이 포함될 가능성이 높으며, 경우에 따라 AWS 메커니즘이 관련될 수도 있습니다. 인프라 영역에서는 포렌식 분석 및 조사 수행 전용 Amazon EC2 인스턴스와 같은 게스트 운영 체제 내에서 AWS API와 디지털 포렌식/인시던트 대응(DFIR) 도구를 조합하여 사용할 수 있습니다. 인프라 영역 인시던트에는 네트워크 패킷 캡처, [Amazon Elastic Block Store](https://aws.amazon.com/ebs/)(Amazon EBS) 볼륨의 디스크 블록 또는 인스턴스에서 획득한 휘발성 메모리 분석이 포함될 수 있습니다.
+ **애플리케이션 영역** - 애플리케이션 영역의 인시던트는 애플리케이션 코드나 서비스 또는 인프라에 배포된 소프트웨어에서 발생합니다. 이 영역은 클라우드 위협 탐지 및 대응 플레이북에 포함되어야 하며 인프라 영역의 대응과 유사한 대응을 통합할 수 있습니다. 적절하고 사려 깊은 애플리케이션 아키텍처를 사용하면 자동 획득, 복구 및 배포를 사용하여 클라우드 도구를 통해 이 영역을 관리할 수 있습니다.
이러한 영역에서는 AWS 계정, 리소스 또는 데이터에 대해 조치를 취할 수 있는 행위자를 고려하세요. 내부 또는 외부에 관계없이 위험 프레임워크를 사용하여 조직에 대한 구체적인 위험을 파악하고 그에 따라 대비하세요. 또한 인시던트 대응 계획과 신중한 아키텍처 구축에 도움이 될 수 있는 위협 모델을 개발해야 합니다.
### AWS에서 인시던트 대응의 주요 차이점
인시던트 대응은 온프레미스 또는 클라우드에서 사이버 보안 전략의 필수적인 부분입니다. 최소 권한, 심층 방어 등의 보안 원칙은 온프레미스와 클라우드 모두에서 데이터의 기밀성, 무결성 및 가용성을 보호하기 위한 것입니다. 로그 보존, 위협 모델링에서 파생된 알림 선택, 플레이북 개발, 보안 정보 및 이벤트 관리(SIEM) 통합 등 이러한 보안 원칙을 뒷받침하는 여러 인시던 대응 패턴도 마찬가지입니다. 고객이 클라우드에서 이러한 패턴을 설계하고 엔지니어링하기 시작할 때부터 차이가 시작됩니다. 다음은 AWS에서 인시던트 대응의 주요 차이입니다.
#### 차이 1: 공동 책임으로서의 보안
보안과 규정 준수에 대한 책임은 AWS와 고객이 공유합니다. 이 공동 책임 모델은 고객의 운영 부담을 덜어줍니다. 호스트 운영 체제 및 가상화 계층부터 서비스 운영 시설의 물리적 보안에 이르는 구성 요소를 AWS에서 운영, 관리 및 제어하기 때문입니다. 공동 책임 모델에 대한 자세한 내용은 [공동 책임 모델](https://aws.amazon.com/compliance/shared-responsibility-model/) 설명서를 참조하세요.
클라우드에서 공동 책임이 변경되면 인시던트 대응 옵션도 변경됩니다. 이러한 상충 관계를 계획 및 이해하고 거버넌스 요구 사항에 맞추는 것은 인시던트 대응의 중요한 단계입니다.
AWS와의 직접적인 관계 외에도 특정 책임 모델에서 책임을 지는 다른 엔터티가 있을 수 있습니다. 예를 들어 운영의 일부 측면을 책임지는 내부 조직 단위가 있을 수 있습니다. 일부 클라우드 기술을 개발, 관리 또는 운영하는 다른 당사자와 관계를 맺고 있을 수도 있습니다.
운영 모델에 맞는 적절한 인시던트 대응 계획과 적절한 플레이북을 생성하고 테스트하는 것이 매우 중요합니다.
#### 차이 2: 클라우드 서비스 영역
클라우드 서비스에 존재하는 보안 책임의 차이로 인해 보안 인시던트에 대한 새로운 영역인 서비스 영역이 도입되었습니다.이는 앞서 [인시던트 영역](#cloud-security-incident-domains) 섹션에서 설명했습니다. 서비스 영역은 고객의 AWS 계정, IAM 권한, 리소스 메타데이터, 결제 및 기타 영역을 포괄합니다. 이 영역은 대응 방식에 따라 인시던트 대응이 달라집니다. 서비스 영역 내의 대응은 일반적으로 기존 호스트 기반 및 네트워크 기반 대응이 아닌 API 직접 호출을 검토하고 실행하는 방식으로 이루어집니다. 서비스 영역에서는 영향을 받는 리소스의 운영 체제와 상호 작용하지 않습니다.
다음 다이어그램은 아키텍처 안티 패턴을 기반으로 하는 서비스 영역의 보안 이벤트 예를 보여줍니다. 이 경우 권한이 없는 사용자는 IAM 사용자의 장기 보안 자격 증명을 얻습니다. IAM 사용자는 [Amazon Simple Storage Service](https://aws.amazon.com/s3/)(Amazon S3) 버킷에서 객체를 검색할 수 있는 IAM 정책을 가지고 있습니다. 이 보안 이벤트에 대응하려면 AWS API를 사용하여 [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) 및 Amazon S3 액세스 로그와 같은 AWS 로그를 분석합니다. 또한 AWS API를 사용하여 인시던트를 격리하고 복구합니다.
![\[서비스 영역 예시의 다이어그램\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/images/service-domain-example.png)
#### 차이 3: 인프라 프로비저닝을 위한 API
또 다른 차이는 [온디맨드 셀프 서비스의 클라우드 특성](https://csrc.nist.gov/publications/detail/sp/800-145/final)에서 비롯됩니다. 주요 시설 고객은 전 세계 여러 지역에서 제공되는 퍼블릭 및 프라이빗 엔드포인트를 통해 RESTful API를 사용하여 AWS 클라우드와 상호 작용합니다. 고객은 AWS 자격 증명을 사용하여 이러한 API에 액세스할 수 있습니다. 온프레미스 액세스 제어와 달리, 이러한 자격 증명은 네트워크 또는 Microsoft Active Directory 도메인에 반드시 구속되지 않습니다. 자격 증명은 대신 AWS 계정 내의 IAM 위탁자와 연결됩니다. 이러한 API 엔드포인트는 회사 네트워크 외부에서 액세스할 수 있으므로 예상 네트워크 또는 지역 외부에서 자격 증명이 사용되는 인시던트에 대응할 때 이해해야 할 중요한 사항입니다.
AWS의 API 기반 특성으로 인해 보안 이벤트에 대응하는 데 중요한 로그 소스는 AWS 계정에서 이루어진 관리 API 직접 호출을 추적하고 API 직접 호출의 소스 위치에 대한 정보를 찾을 수 있는 AWS CloudTrail입니다.
#### 차이 4: 클라우드의 동적 특성
클라우드는 동적이므로 리소스를 빠르게 생성하고 삭제할 수 있습니다. 오토 스케일링을 사용하면 트래픽 증가에 따라 리소스를 스핀 업하고 스핀 다운할 수 있습니다. 수명이 짧은 인프라와 빠른 변경으로 인해 조사 중인 리소스가 더 이상 존재하지 않거나 수정되었을 수 있습니다. AWS 리소스의 임시 특성과 AWS 리소스 생성 및 삭제를 추적하는 방법을 이해하는 것이 인시던트 분석에 중요합니다. [AWS Config](https://aws.amazon.com/config/)를 사용하여 AWS 리소스의 구성 기록을 추적할 수 있습니다.
#### 차이 5: 데이터 액세스
클라우드에서는 데이터 액세스도 다릅니다. 보안 조사에 필요한 데이터를 수집하기 위해 서버에 연결할 수 없습니다. 데이터는 유선 및 API 직접 호출을 통해 수집됩니다. 이러한 변화에 대비하려면 API를 통해 데이터를 수집하는 방법을 연습하고 이해해야 하며, 효과적인 수집 및 액세스를 위해 적절한 스토리지를 확인해야 합니다.
#### 차이 6: 자동화의 중요성
고객이 클라우드 채택의 이점을 완전히 실현하려면 운영 전략에 자동화가 포함되어야 합니다. 코드형 인프라(IaC)는 [AWS CloudFormation](https://aws.amazon.com/cloudformation/)이나 타사 솔루션과 같은 기본 IaC 서비스에서 지원하는 코드를 사용하여 AWS 서비스를 배포, 구성, 재구성 및 폐기하는 매우 효율적인 자동화 환경의 패턴입니다. 이를 통해 인시던트 대응 구현이 고도로 자동화되며, 특히 증거를 처리할 때 인적 실수를 방지하는 데 유리합니다. 자동화는 온프레미스에서 사용되지만 AWS 클라우드에서는 더 간단하고 필수적입니다.
#### 이러한 차이 해소
이러한 차이를 해소하려면 다음 섹션에 설명된 단계에 따라 사람, 프로세스 및 기술 전반의 인시던트 대응 프로그램이 잘 준비되었는지 확인합니다.
# 준비
인시던트 대비는 시기적절하고 효과적인 인시던트 대응을 위해 매우 중요합니다. 준비는 세 가지 영역에서 이루어집니다.
+ **사람** - 보안 인시던트에 대비하려면 인시던트 대응을 위한 관련 이해관계자를 식별하고 인시던트 대응 및 클라우드 기술에 대해 교육해야 합니다.
+ **프로세스** - 보안 인시던트에 대비하여 프로세스를 준비하려면 아키텍처 문서화, 철저한 인시던트 대응 계획 개발, 보안 이벤트에 대한 일관된 대응을 위한 플레이북 작성이 포함됩니다.
+ **기술** - 보안 인시던트에 대비한 기술 준비에는 액세스 설정, 필요한 로그 집계 및 모니터링, 효과적인 알림 메커니즘 구현, 대응 및 조사 기능 개발이 포함됩니다.
이러한 각 영역은 효과적인 인시던트 대응을 위해 동일하게 중요합니다. 이 세 가지가 모두 없으면 인시던트 대응 프로그램이 완전하거나 효과적이지 않습니다. 인시던트에 대비하려면 긴밀한 통합을 통해 직원, 프로세스 및 기술을 준비해야 합니다.
# 사람
보안 이벤트에 대응하려면 보안 이벤트에 대한 대응을 지원할 이해관계자를 식별해야 합니다. 또한 효과적인 대응을 위해서는 이해관계자를 대상으로 AWS 기술과 AWS 환경에 대한 교육을 실시하는 것이 중요합니다.
# 역할과 책임 정의
보안 이벤트를 처리하려면 조직 간 규율과 행동 성향이 필요합니다. 조직 구조 내에는 인사(HR) 담당자, 경영진, 법무 담당자와 같이 인시던트 발생 시 책임이 있거나(Responsible) 책임을 지거나(Accountable) 자문을 받거나(Consulted) 최신 정보를 제공받는(Informed) 사람들이 많이 있어야 합니다. 이러한 역할 및 책임과 제3자가 개입해야 하는지 여부를 고려합니다. 많은 지역에 해야 할 일과 하지 말아야 할 일을 규정하는 현지 법률이 있습니다. 보안 대응 계획을 위해 RACI(Responsible, Accountable, Consulted, Informed) 차트를 작성하는 것이 불필요해 보일 수 있지만, 그렇게 하면 신속하고 직접적인 커뮤니케이션이 가능하고 이벤트의 여러 단계에서 리더십의 윤곽을 명확하게 파악할 수 있습니다.
인시던트 발생 시 영향을 받는 애플리케이션 및 리소스의 소유자/개발자를 포함하는 것이 중요합니다. 이들은 영향을 측정하는 데 도움이 되는 정보와 컨텍스트를 제공할 수 있는 분야별 전문가(SME)이기 때문입니다. 개발자 및 애플리케이션 소유자의 인시던트 대응 전문 지식에 의존하기 전에 이들과 함께 연습하고 관계를 구축해야 합니다. 클라우드 관리자 또는 엔지니어와 같은 애플리케이션 소유자 또는 SME는 환경이 익숙하지 않거나 복잡하거나 대응자가 액세스할 수 없는 상황에서 조치를 취해야 할 수 있습니다.
마지막으로 신뢰할 수 있는 관계는 추가적인 전문 지식과 가치 있는 조사를 제공할 수 있으므로 조사 또는 대응에 참여할 수 있습니다. 팀에 이러한 기술이 없다면 외부 담당자를 고용하여 도움을 받는 것이 좋습니다.
# 인시던트 대응 직원 교육
인시던트 대응 직원을 대상으로 조직에서 사용하는 기술에 대한 교육을 실시하는 것은 보안 이벤트에 적절하게 대응하는 데 매우 중요합니다. 직원이 기본 기술을 이해하지 못하면 대응이 늦어질 수 있습니다. 기존의 인시던트 대응 개념 외에도 AWS 서비스와 AWS 환경을 이해하는 것도 중요합니다. 온라인 교육 및 강의실 교육 등 인시던트 직원을 교육하는 데는 여러 가지 전통적인 메커니즘이 있습니다. 또한 교육 메커니즘으로 게임데이 또는 시뮬레이션을 실행하는 것도 고려해야 합니다. 시뮬레이션을 실행하는 방법에 대한 자세한 내용은 이 문서의 [정기 시뮬레이션 실행](run-regular-simulations.md) 섹션을 참조하세요.
# AWS 클라우드 기술 이해
종속성을 줄이고 대응 시간을 줄이려면 보안 팀과 대응 담당자가 클라우드 서비스에 대한 교육을 받고 조직에서 사용하는 특정 클라우드 환경에서 실습할 기회를 얻어야 합니다. 인시던트 대응 담당자가 효과적으로 대응하려면 AWS 파운데이션, IAM, AWS Organizations, AWS 로깅 및 모니터링 서비스, AWS 보안 서비스를 이해하는 것이 중요합니다.
AWS는 AWS 보안 및 모니터링 서비스에 대한 실습 경험을 얻을 수 있는 온라인 보안 워크숍([AWS 보안 워크숍 참조](https://workshops.aws/categories/Security))을 제공합니다. 또한 AWS는 디지털 교육, 강의실 교육, AWS 교육 파트너 및 인증을 통해 다양한 교육 옵션과 학습 경로를 제공합니다. 자세한 내용은 [AWS 교육 및 자격증](https://aws.amazon.com/training/)을 참조하세요.
AWS는 여러 페르소나와 중점 영역을 지원하는 무료 교육과 구독 기반 교육을 모두 제공합니다. 자세한 내용은 [AWS Skillbuilder](https://skillbuilder.aws/)를 참조하세요.
# AWS 환경 이해
AWS 서비스와 그 사용 사례, 그리고 서비스 간의 통합 방식을 이해하는 것 외에도, 조직의 AWS 환경이 실제로 어떻게 설계되었는지, 어떤 운영 프로세스가 마련되어 있는지 이해하는 것도 마찬가지로 중요합니다. 이러한 내부 지식은 문서화되지 않고 소수의 영역 전문가만 이해하는 경우가 많기 때문에 종속성이 발생하고 혁신을 저해하며 대응 시간이 느려질 수 있습니다.
이러한 종속성을 방지하고 대응 시간을 단축하려면 보안 분석가가 AWS 환경에 대한 내부 지식을 문서화하고, 액세스하고, 이해할 수 있어야 합니다. 클라우드의 전체 현황을 파악하려면 관련 보안 이해관계자와 클라우드 관리자 간 협업이 필요합니다. 인시던트 대응을 위한 프로세스를 준비하는 작업에는 아키텍처 다이어그램 문서화와 중앙 중앙화가 포함되는데, 이에 대한 내용은 이 백서 뒷부분의 [아키텍처 다이어그램 문서화 및 중앙 집중화](document-and-centralize-architecture-diagrams.md)에 나와 있습니다. 하지만 사람의 관점에서 보면 분석가가 AWS 환경과 관련된 다이어그램과 운영 프로세스에 액세스하고 이해할 수 있는 것이 중요합니다.
# AWS 대응 팀 및 지원 이해
## 지원
[지원](https://aws.amazon.com/premiumsupport/)는 다양한 플랜을 제공합니다. 이러한 플랜을 통해 AWS 솔루션의 성공과 운영 상태를 지원하는 도구 및 전문 지식에 액세스할 수 있습니다. AWS 환경을 계획, 배포, 최적화하는 데 도움이 되는 기술 지원 및 추가 리소스가 필요한 경우 AWS 사용 사례에 가장 적합한 지원 플랜을 선택할 수 있습니다.
AWS Management Console의 [지원 센터](https://console.aws.amazon.com/support)(로그인이 필요함)를 AWS 리소스에 영향을 미치는 문제에 대한 지원을 받을 수 있는 중앙 연락 창구로 고려하세요. 지원에 대한 액세스는 IAM으로 제어됩니다. AWS Support 기능에 액세스하는 방법에 대한 자세한 내용은 [Getting started with 지원](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html#accessing-support)를 참조하세요.
또한 침해를 보고해야 하는 경우 [AWS 신뢰 안전 팀](https://aws.amazon.com/forms/report-abuse)에 문의하세요.
## Security Incident Response 엔지니어
Security Incident Response 엔지니어는 상시 운영되는 전문 글로벌 AWS 팀으로, [AWS 공동 책임 모델](https://aws.amazon.com/compliance/shared-responsibility-model/)의 고객 측에서 활성 보안 이벤트가 진행되는 동안 고객에게 지원을 제공합니다.
Security Incident Response 엔지니어의 지원을 받으면 AWS에서 활성 보안 이벤트에 대한 분류 및 복구에 대한 지원을 받게 됩니다. 팀은 AWS 서비스 로그를 사용하여 근본 원인 분석을 지원하고 복구를 위한 권장 사항을 제공할 수 있습니다. 또한 향후 보안 이벤트를 방지하는 데 도움이 되는 보안 권장 사항 및 모범 사례를 제공합니다.
AWS 고객은 [AWS 지원 사례](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html)를 통해 Security Incident Response 엔지니어를 참여시킬 수 있습니다.
+ **모든 고객**:
1. 계정 및 청구(Account and billing)
1. 서비스: 계정
1. 범주: 보안
1. 심각도: 일반 질문
+ **Developer 지원 플랜을 사용하는 고객**:
1. 계정 및 청구(Account and billing)
1. 서비스: 계정
1. 범주: 보안
1. 심각도: 중요 질문
+ **Business 지원 플랜을 사용하는 고객**:
1. 계정 및 청구(Account and billing)
1. 서비스: 계정
1. 범주: 보안
1. 심각도: 비즈니스에 영향을 미치는 긴급한 질문
+ **Enterprise 지원 플랜을 사용하는 고객**:
1. 계정 및 청구(Account and billing)
1. 서비스: 계정
1. 범주: 보안
1. 심각도: 중요한 비즈니스 위험 질문
+ **AWS Security Incident Response 구독을 사용하는 고객**: https://console.aws.amazon.com/security-ir/에서 Security Incident Response 콘솔을 엽니다.
## DDoS 대응 지원
AWS는 [AWS Shield](https://aws.amazon.com/shield/)를 제공합니다. 이 서비스는 AWS에서 실행되는 웹 애플리케이션을 보호하는 관리형 분산 서비스 거부(DDoS) 보호 서비스입니다. AWS Shield는 상시 탐지 및 자동 인라인 완화 기능을 제공하여 애플리케이션 가동 중지 시간과 지연 시간을 최소화하므로, DDoS 보호 혜택을 받기 위해 지원에 문의할 필요가 없습니다. AWS Shield에는 Shield Standard와 Shield Advanced, 두 가지 계층이 있습니다. 이 두 티어의 차이점에 대해 알아보려면 [Shield 기능 설명서](https://aws.amazon.com/shield/features/)를 참조하세요.
## AWS Managed Services(AMS)
[AWS Managed Services](https://aws.amazon.com/managed-services/)(AMS)에서는 AWS 인프라를 지속적으로 관리하므로 사용자는 애플리케이션에 집중할 수 있습니다. 인프라를 유지 관리하기 위한 모범 사례를 구현함으로써 AMS는 운영 오버헤드와 위험을 줄이도록 지원합니다. AMS는 변경 요청, 모니터링, 패치 관리, 보안, 백업 서비스 등과 같은 일반적인 활동을 자동화하고 인프라를 프로비저닝, 운영 및 지원하기 위한 전체 수명 주기 서비스를 제공합니다.
AMS는 일련의 보안 탐지 제어를 배포하고 알림에 대한 일차 대응을 상시 제공합니다. 경고가 시작되면 AMS는 일련의 표준 자동 및 수동 플레이북에 따라 일관된 응답을 확인합니다. 이러한 플레이북은 온보딩 중에 AMS 고객과 공유되므로 고객이 AMS를 통해 대응 방안을 개발하고 조정할 수 있습니다.
# 프로세스
철저하고 명확하게 정의된 인시던트 대응 프로세스를 개발하는 것은 성공적이고 확장 가능한 인시던트 대응 프로그램의 핵심입니다. 보안 이벤트가 발생하면 명확한 단계 및 워크플로가 적시에 대응하는 데 도움이 됩니다. 기존 인시던트 대응 프로세스가 이미 있을 수 있습니다. 현재 상태에 관계없이 인시던트 대응 프로세스를 정기적으로 업데이트, 반복, 테스트하는 것이 중요합니다.
# 인시던트 대응 계획 개발 및 테스트
인시던트 대응을 위해 작성해야 할 첫 번째 문서는 *인시던트 대응 계획*입니다. 인시던트 대응 계획은 인시던트 대응 프로그램 및 전략의 기초가 되도록 설계되었습니다. 인시던트 대응 계획은 일반적으로 다음 섹션을 포함하는 개요 수준의 문서입니다.
+ **인시던트 대응 팀 개요** - 인시던트 대응 팀의 목표와 기능을 간략하게 설명합니다.
+ **역할 및 책임** - 인시던트 대응 이해관계자를 나열하고 인시던트 발생 시 해당 이해관계자의 역할을 자세히 설명합니다.
+ **커뮤니케이션 계획** - 연락처 정보 및 인시던트 발생 시 커뮤니케이션 방법을 자세히 설명합니다.
인시던트 커뮤니케이션의 백업으로 대역 외 통신을 사용하는 것이 모범 사례입니다. 안전한 대역 외 통신 채널을 제공하는 애플리케이션의 예는 [AWS Wickr](https://aws.amazon.com/wickr/)입니다.
+ **인시던트 대응 단계 및 수행할 조치** - 인시던트 대응의 단계(예: 탐지, 분석, 근절, 방지, 복구)를 열거합니다. 여기에는 해당 단계 내에서 취해야 할 상위 수준 조치가 포함됩니다.
+ **인시던트 심각도 및 우선순위 정의** - 인시던트의 심각도를 분류하는 방법, 인시던트의 우선순위를 지정하는 방법, 심각도 정의가 에스컬레이션 절차에 미치는 영향을 자세히 설명합니다.
이러한 섹션은 규모 및 업종이 다른 회사 간에 공통적으로 사용되지만 각 조직의 인시던트 대응 계획은 고유합니다. 조직에 가장 적합한 인시던트 대응 계획을 수립해야 합니다.
# 아키텍처 다이어그램 문서화 및 중앙 집중화
보안 이벤트에 빠르고 정확하게 대응하려면 시스템과 네트워크가 어떻게 설계되는지 이해해야 합니다. 이러한 내부 패턴을 이해하는 것은 인시던트 대응뿐만 아니라 모범 사례에 따라 패턴이 설계된 애플리케이션 전반의 일관성을 확인하는 데에도 중요합니다. 또한 이 설명서가 최신 상태이고 새 아키텍처 패턴에 따라 정기적으로 업데이트되는지 확인해야 합니다. 다음과 같은 항목을 자세히 설명하는 설명서와 내부 리포지토리를 개발해야 합니다.
+ **AWS 계정 구조** - 다음을 알아야 합니다.
+ AWS 계정이 몇 개 있나요?
+ 이러한 AWS 계정은 어떻게 구성되나요?
+ AWS 계정의 비즈니스 소유자는 누구인가요?
+ 서비스 제어 정책(SCP)을 사용하시나요? 그렇다면 SCP를 사용하여 구현되는 조직 가드레일은 무엇인가요?
+ 사용할 수 있는 리전과 서비스를 제한하나요?
+ 사업부와 환경(개발/테스트/프로덕션) 간에는 어떤 차이가 있나요?
+ **AWS 서비스 패턴**
+ 어떤 AWS 서비스를 사용하나요?
+ 가장 널리 사용되는 AWS 서비스는 무엇인가요?
+ **아키텍처 패턴**
+ 어떤 클라우드 아키텍처를 사용하나요?
+ **AWS 인증 패턴**
+ 개발자는 일반적으로 AWS에 어떻게 인증하나요?
+ IAM 역할, 사용자 또는 둘 다 사용하나요? AWS에 대한 인증이 ID 제공업체(idP)에 연결되어 있나요?
+ IAM 역할 또는 사용자를 직원 또는 시스템에 어떻게 매핑하나요?
+ 더 이상 권한이 없는 경우 어떻게 액세스 권한이 취소되나요?
+ **AWS 권한 부여 패턴**
+ 개발자는 어떤 IAM 정책을 사용하나요?
+ 리소스 기반 정책을 사용하시나요?
+ **로깅 및 모니터링**
+ 어떤 로깅 소스를 사용하며 어디에 저장되나요?
+ AWS CloudTrail 로그를 집계하나요? 그렇다면 어디에 저장되나요?
+ CloudTrail 로그를 쿼리하려면 어떻게 해야 하나요?
+ Amazon GuardDuty를 활성화했나요?
+ GuardDuty 조사 결과(예: 콘솔, 티켓팅 시스템, SIEM)에 액세스하려면 어떻게 해야 하나요?
+ 조사 결과 또는 이벤트가 SIEM에서 집계되나요?
+ 티켓이 자동으로 생성되나요?
+ 조사를 위해 로그를 분석하기 위한 도구에는 어떤 것이 있나요?
+ **네트워크 토폴로지**
+ 네트워크의 디바이스, 엔드포인트 및 연결은 물리적 또는 논리적으로 어떻게 배열되나요?
+ 네트워크는 AWS와 어떻게 연결되나요?
+ 환경 간에 네트워크 트래픽은 어떻게 필터링되나요?
+ **외부 인프라**
+ 외부용 애플리케이션은 어떻게 배포되나요?
+ 공개적으로 액세스할 수 있는 AWS 리소스에는 어떤 것이 있나요?
+ 외부로 향하는 인프라가 포함된 AWS 계정에는 어떤 것이 있나요?
+ 어떤 DDoS 또는 외부 필터링이 있나요?
내부 기술 다이어그램과 프로세스를 문서화하면 인시던트 대응 분석가의 작업이 쉬워지므로 보안 이벤트에 대응할 수 있는 제도적 지식을 빠르게 얻을 수 있습니다. 내부 기술 프로세스를 철저히 문서화하면 보안 조사가 간소화될 뿐만 아니라 프로세스의 합리화 및 평가에도 도움이 됩니다.
# 인시던트 대응 개발 플레이북
인시던트 대응 프로세스를 준비하는 데 있어 가장 중요한 부분은 플레이북을 개발하는 것입니다. 인시던트 대응 플레이북은 보안 이벤트가 발생했을 때 따라야 할 일련의 권장 가이드와 단계를 제공합니다. 명확한 구조와 단계를 갖추면 대응 프로세스가 간소화되고 인적 오류의 가능성이 줄어듭니다.
# 플레이북 작성 대상
다음과 같은 인시던트 시나리오에 대한 플레이북을 만들어야 합니다.
+ **예상되는 인시던트** - 예상되는 인시던트에 대한 플레이북을 만들어야 합니다. 여기에는 서비스 거부(DoS), 랜섬웨어, 자격 증명 유출과 같은 위협이 포함됩니다.
+ **알려진 보안 조사 결과 또는 알림** - 알려진 보안 조사 결과 및 알림(예: GuardDuty 조사 결과)에 대한 플레이북을 만들어야 합니다. GuardDuty 조사 결과를 받고 '이제 어떡하지?'라고 생각할 수 있습니다. GuardDuty 조사 결과를 잘못 처리하거나 무시하는 것을 방지하려면 잠재적인 GuardDuty 조사 결과에 대한 플레이북을 만드세요. 일부 수정 세부 사항과 지침은 [GuardDuty 설명서](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html)에 나와 있습니다. GuardDuty는 기본적으로 활성화되어 있지 않으며 사용 시 별도의 비용이 발생한다는 점에 유의하세요. GuardDuty에 대한 자세한 내용은 부록 A: 클라우드 기능 정의 - [가시성 및 알림](visibility-and-alerting.md)에서 확인할 수 있습니다.
# 플레이북 포함 대상
플레이북에는 보안 분석가가 잠재적인 보안 인시던트를 적절히 조사하고 대응하기 위해 완료해야 할 기술 단계가 포함되어야 합니다.
플레이북에 포함할 항목은 다음과 같습니다.
+ **플레이북 개요** - 이 플레이북은 어떤 위험 또는 인시던트 시나리오를 다루고 있나요? 플레이북의 목표는 무엇인가요?
+ **사전 조건** - 이 인시던트 시나리오에 어떤 로그 및 탐지 메커니즘이 필요한가요? 예상되는 알림은 무엇인가요?
+ ** 이해관계자 정보** - 관련자는 누구이며 연락처 정보는 어떻게 되나요? 관련된 각 이해관계자의 책임은 무엇인가요?
+ **대응 단계** - 인시던트 대응 단계 전반에서 어떤 전술적 단계를 수행해야 하나요? 분석가는 어떤 쿼리를 실행해야 하나요? 원하는 결과를 얻으려면 어떤 코드를 실행해야 하나요?
+ **탐지** - 어떻게 인시던트를 탐지하나요?
+ **분석** - 어떻게 영향 범위를 결정하나요?
+ **격리** - 범위를 제한하기 위해 어떻게 인시던트를 격리하나요?
+ **근절** - 환경에서 위협을 어떻게 제거하나요?
+ **복구** - 영향을 받은 시스템이나 리소스를 어떻게 프로덕션 환경으로 복구하나요?
+ **예상 결과** - 쿼리와 코드가 실행된 후 플레이북의 예상 결과는 무엇인가요?
각 플레이북에서 일관된 정보를 확인하려면 다른 보안 플레이북에서 사용할 플레이북 템플릿을 생성하는 것이 유용할 수 있습니다. 이해관계자 정보와 같이 이전에 나열된 항목 중 일부를 여러 플레이북에서 공유할 수 있습니다. 그렇다면 해당 정보에 대한 중앙 집중식 문서를 만들고 플레이북에서 참조한 다음 플레이북에 명확한 차이점을 열거할 수 있습니다. 이렇게 하면 모든 개별 플레이북에서 동일한 정보를 업데이트할 필요가 없습니다. 플레이북에서 템플릿을 만들고 공통적이거나 공유되는 정보를 식별하면 플레이북 개발을 간소화하고 가속화할 수 있습니다. 마지막으로, 플레이북은 시간이 지남에 따라 진화할 가능성이 높으며, 단계가 일관성이 있음이 확인되면 자동화를 위한 요구 사항이 형성됩니다.
# 샘플 플레이북
부록 B의 [플레이북 리소스](appendix-b-incident-response-resources.md#playbook-resources)에서 여러 가지 샘플 플레이북을 찾을 수 있습니다. 여기의 예시는 어떤 플레이북을 만들어야 하는지, 플레이북에 무엇을 포함해야 하는지에 대한 지침을 제공하는 데 도움이 될 수 있습니다. 그러나 비즈니스와 가장 관련성 있는 위험을 통합한 플레이북을 만드는 것이 중요합니다. 플레이북 내의 단계와 워크플로에 기술과 프로세스가 포함되어 있는지 확인해야 합니다.
# 정기 시뮬레이션 실행
조직은 시간이 지남에 따라 성장하고 진화하며, 위협 환경도 마찬가지입니다. 이러한 이유로 인시던트 대응 역량을 지속적으로 검토하는 것이 중요합니다. 이 평가를 수행하는 데 사용할 수 있는 한 가지 방법은 시뮬레이션입니다. 시뮬레이션은 위협 행위자의 전술, 기술 및 절차(TTP)를 모방하도록 설계된 실제 보안 이벤트 시나리오를 사용하며, 이를 통해 조직은 이러한 모의 사이버 이벤트에 실제 상황과 같이 대응하여 인시던트 대응 능력을 발휘하고 평가할 수 있습니다.
시뮬레이션에는 다음과 같은 다양한 이점이 있습니다.
+ 사이버 대비 상태를 검증하고 인시던트 대응자의 자신감을 높입니다.
+ 도구 및 워크플로의 정확성과 효율성을 테스트합니다.
+ 인시던트 대응 계획에 맞춰 커뮤니케이션 및 에스컬레이션 방법을 개선합니다.
+ 덜 일반적인 벡터에 대응할 수 있는 기회를 제공합니다.
# 시뮬레이션 유형
시뮬레이션에는 다음과 같은 세 가지 주요 유형이 있습니다.
+ **탁상 연습** - 시뮬레이션에 대한 탁상 접근 방식은 다양한 인시던트 대응 이해관계자가 참여하여 책임진 역할을 연습하고 확립된 커뮤니케이션 도구와 플레이북을 사용하는 토론 기반 세션입니다. 연습은 일반적으로 가상 장소, 실제 장소 또는 이들 장소의 조합에서 하루 종일 수행할 수 있어 언제든 촉진시킬 수 있습니다. 토론을 기반으로 하는 특성상 탁상 연습은 프로세스, 사람, 협업에 중점을 둡니다. 기술은 토론의 핵심 부분이지만 인시던트 대응 도구 또는 스크립트의 실제 사용은 일반적으로 탁상 연습의 일부가 아닙니다.
+ **퍼플 팀 연습** - 퍼플 팀 연습은 인시던트 대응 담당자(*블루 팀*)와 시뮬레이션된 위협 행위자(*레드 팀*) 간의 협업 수준을 높입니다. 블루 팀은 보안 운영 센터(SOC)의 직원으로 구성되지만 실제 사이버 이벤트 중에 관여하게 될 다른 이해관계자들도 포함될 수 있습니다. 레드 팀은 대개 보안 공격 교육을 받은 침투 테스트 팀 또는 주요 이해관계자로 구성됩니다. 레드 팀은 시나리오를 설계할 때 연습 진행자와 협력하여 시나리오가 정확하고 실현 가능한지 확인합니다. 퍼플 팀 연습에서는 인시던트 대응 작업을 지원하는 탐지 메커니즘, 도구 및 표준 운영 절차(SOP)에 주로 초점을 맞춥니다.
+ **레드 팀 연습** - 레드 팀 연습 중에 공격 팀(*레드 팀*)은 미리 정해진 범위에서 특정 목표 또는 일련의 목표를 달성하기 위해 시뮬레이션을 수행합니다. 방어 팀(*블루 팀*)은 훈련의 범위와 기간을 꼭 알 필요가 없습니다. 이를 모르면 실제 인시던트에 어떻게 대응하는지에 대한 더 현실적인 평가를 받을 수 있습니다. 레드 팀 연습은 침습적 테스트일 수 있으므로 주의가 필요하고 해당 연습이 환경에 실제로 해를 끼치지 않는지 확인하기 위한 관리 조치를 취해야 합니다.
**참고**
AWS에서는 고객이 퍼플 팀이나 레드 팀 훈련을 실시하기 전에 [침투 테스트 웹 사이트](https://aws.amazon.com/security/penetration-testing/)에서 제공하는 침투 테스트 정책을 검토하도록 요구합니다.
표 1에는 이러한 유형의 시뮬레이션의 몇 가지 주요 차이점이 요약되어 있습니다. 일반적으로 이러한 정의는 포괄적인 정의로 간주되며 조직의 요구 사항에 맞게 사용자 지정할 수 있다는 점에 유의해야 합니다.
*표 1 - 시뮬레이션 유형*
| | 테이블탑 연습 | 퍼플 팀 연습 | 레드 팀 연습 |
| --- | --- | --- | --- |
| 요약 | 특정 보안 인시던트 시나리오 하나에 초점을 맞춘 종이 기반 연습. 이는 개괄적 또는 기술적일 수 있으며 일련의 종이 주입을 통해 구동됩니다. | 테이블탑 연습에 비해 더 사실적인 오퍼링. 퍼플 팀 연습 중 진행자는 참가자와 협력하여 연습 참여를 높이고 필요한 경우 훈련을 제공합니다. | 일반적으로 보다 진보된 시뮬레이션 오퍼링. 일반적으로 비밀 유지 수준이 높아서 참가자들이 연습의 모든 세부 사항을 알지 못할 수도 있습니다. |
| 필요 리소스 | 제한된 기술 리소스 필요 | 다양한 이해관계자와 높은 수준의 기술 리소스 필요 | 다양한 이해관계자와 높은 수준의 기술 리소스 필요 |
| 복잡성 | 낮음 | 중간 | 높음 |
정기적으로 사이버 시뮬레이션을 진행하는 것이 좋습니다. 각 연습 유형에는 참가자와 조직 전체에 대한 고유한 이점이 있으므로 덜 복잡한 시뮬레이션 유형(예: 탁상 연습)에서 시작하여 더 복잡한 시뮬레이션 유형(레드 팀 연습)으로 진행할 수 있습니다. 보안 성숙도, 리소스, 원하는 성과에 따라 시뮬레이션 유형을 선택해야 합니다. 일부 고객은 복잡성과 비용 때문에 레드 팀 연습을 선택하지 않을 수 있습니다.
# 연습 수명 주기
선택한 유형에 관계없이 시뮬레이션은 일반적으로 다음 단계를 따릅니다.
1. **핵심 연습 요소 정의** - 시뮬레이션의 시나리오와 목표를 정의합니다. 이 두 가지 모두 리더의 승인을 받아야 합니다.
1. **주요 이해관계자 식별** - 연습에는 최소한 연습 진행자와 참가자가 필요합니다. 시나리오에 따라 법무, 커뮤니케이션 또는 경영진과 같은 추가 이해관계자가 참여할 수 있습니다.
1. **시나리오 구축 및 테스트** - 특정 요소가 실현 가능하지 않은 경우 구축 중인 시나리오를 재정의해야 할 수 있습니다. 이 단계의 결과로 최종 시나리오가 도출될 것으로 예상됩니다.
1. **시뮬레이션 촉진** - 시뮬레이션 유형에 따라 어떤 방법으로 촉진시킬지 결정됩니다(종이를 사용한 시나리오 또는 고도로 기술적인 시뮬레이션 시나리오). 진행자는 연습 목표에 맞게 촉진 전략을 조정해야 하며 가능한 한 모든 연습 참가자를 참여시켜 최대한의 이점을 확보해야 합니다.
1. **사후 조치 보고서(AAR) 개발** - 잘 운영된 영역, 개선이 필요한 영역, 잠재적인 격차를 식별합니다. AAR은 시뮬레이션의 효과와 시뮬레이션된 이벤트에 대한 팀의 반응을 측정하여 향후 시뮬레이션을 통해 시간의 흐름에 따른 진행 상황을 추적할 수 있도록 해야 합니다.
# 기술
보안 인시던트 전에 적절한 기술을 개발하고 구현하면 인시던트 대응 직원이 조사하고, 범위를 이해하고, 적시에 조치를 취할 수 있습니다.
# AWS 계정 구조 개발
[AWS Organizations](https://aws.amazon.com/organizations/)는 AWS 리소스의 성장과 규모 조정에 따라 AWS 환경을 중앙에서 관리하고 제어할 수 있도록 도와줍니다. AWS 조직은 AWS 계정을 통합하여 단일 단위로 관리할 수 있도록 합니다. 조직 단위(OU)를 사용하면 계정을 그룹으로 만들어 단일 유닛으로 관리할 수 있습니다.
인시던트 대응에는 *보안 OU* 및 *포렌식 OU*를 포함하는 인시던트 대응 기능을 지원하는 AWS 계정 구조를 갖는 것이 도움이 됩니다. 보안 OU 내에는 다음에 대한 계정이 있어야 합니다.
+ ** 로그 아카이브 **- 로그 아카이브 AWS 계정의 로그를 집계합니다.
+ **보안 도구** - 보안 도구 AWS 계정에서 보안 서비스를 중앙 집중화합니다. 이 계정은 보안 서비스에 대한 위임된 관리자 역할을 합니다.
포렌식 OU 내에서, 비즈니스와 운영 모델에 가장 적합한 것에 따라 운영하는 각 리전에 대해 단일 포렌식 계정 또는 여러 개의 계정을 구현할 수 있는 옵션이 있습니다. 리전별 계정 접근 방식의 예로 미국 동부(버지니아 북부)(us-east-1)와 미국 서부(오리건)(us-west-2)에서만 운영하는 경우 포렌식 OU에는 us-east-1용 계정과 us-west-2용 계정의 두 계정이 있습니다. 새 계정을 프로비저닝하는 데는 시간이 걸리므로, 인시던트 발생 훨씬 전에 포렌식 계정을 생성하고 계측하여 대응 담당자가 대응에 효과적으로 사용할 수 있도록 준비하는 것이 필수적입니다.
다음 다이어그램은 리전별 포렌식 계정이 있는 포렌식 OU를 포함한 샘플 계정 구조를 보여줍니다.
![\[인시던트 대응을 위한 리전별 계정 구조의 다이어그램\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/images/incident-response-account-structure.png)
# 태그 지정 전략 개발 및 구현
AWS 리소스를 사용하는 비즈니스 사용 사례와 관련 내부 이해관계자에 대한 컨텍스트 정보를 얻는 것은 어려울 수 있습니다. 한 가지 방법은 AWS 리소스에 메타데이터를 할당하고 사용자 정의 키와 값으로 구성되는 태그의 형태를 사용하는 것입니다. 태그를 생성하여 리소스를 목적, 소유자, 환경, 처리되는 데이터 유형 및 기타 원하는 기준에 따라 분류할 수 있습니다.
일관된 태그 전략을 사용하면 AWS 리소스에 대한 컨텍스트 정보를 신속하게 식별할 수 있으므로 대응 시간을 단축할 수 있습니다. 태그는 응답 자동화를 시작하는 메커니즘으로도 사용할 수 있습니다. 태그를 지정할 항목에 대한 자세한 내용은 [AWS 리소스 태깅에 대한 설명서](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)를 참조하세요. 먼저 조직 전체에 구현할 태그를 정의하는 것이 좋습니다. 그런 다음 이 태그 지정 전략을 구현하고 적용합니다. 구현 및 시행에 대한 자세한 내용은 AWS 블로그 [Implement AWS resource tagging strategy using AWS Tag Policies and Service Control Policies (SCPs)](https://aws.amazon.com/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps/)를 참조하세요.
# AWS 계정 연락처 정보 업데이트
각 AWS 계정에는 정확하고 최신 연락처 정보가 있어야 합니다. 그래야 해당 이해관계자가 보안, 결제, 운영 등의 주제에 대한 AWS의 중요한 알림을 받을 수 있습니다. 각 AWS 계정에는 보안, 결제, 운영을 담당하는 기본 연락처와 대체 연락처가 있습니다. 이러한 연락처 간의 차이점은 [AWS 계정 관리 참조 안내서](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html#manage-acct-update-contact-alternate)에서 확인할 수 있습니다.
대체 연락처 관리에 대한 자세한 내용은 [대체 연락처 추가, 변경 또는 제거에 대한 AWS 설명서](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-account-payment.html#manage-account-payment-alternate-contacts)를 참조하세요. 팀에서 결제, 운영 및 보안 관련 문제를 관리하는 경우 이메일 배포 목록을 사용하는 것이 가장 좋습니다. 이메일 배포 목록은 부재 또는 퇴사 시 막힘을 유발할 수 있는 한 사람에 대한 종속성을 없앱니다. 또한 전화번호를 포함한 이메일 및 계정 연락처 정보가 루트 계정 암호 재설정 및 다중 인증(MFA) 재설정으로부터 안전하게 보호되는지 확인해야 합니다.
AWS Organizations를 사용하는 고객의 경우 조직 관리자는 각 AWS 계정에 대한 자격 증명 없이 관리 계정 또는 위임 관리자 계정을 사용하여 멤버 계정의 대체 연락처를 중앙에서 관리할 수 있습니다. 또한 새로 생성된 계정에 정확한 연락처 정보가 있는지 확인해야 합니다. [Automatically update alternate contacts for newly created AWS 계정 블로그 게시물](https://aws.amazon.com/blogs/mt/automatically-update-alternate-contacts-for-newly-created-aws-accounts/)을 참조하세요.
# AWS 계정에 대한 액세스 준비
인시던트 중 인시던트 대응 팀은 인시던트와 관련된 환경과 리소스에 액세스할 수 있어야 합니다. 이벤트가 발생하기 전에 팀이 업무를 수행할 수 있는 적절한 액세스 권한을 가지고 있는지 확인합니다. 이를 위해서는 팀원에게 필요한 액세스 권한 수준(예: 어떤 종류의 작업을 수행할 가능성이 높은지)을 파악하고 최소 권한 액세스 권한을 미리 프로비저닝해야 합니다.
이 액세스를 구현하고 프로비저닝하려면 조직의 클라우드 아키텍트와 함께 AWS 계정 전략 및 클라우드 ID 전략을 식별하고 논의하여 구성된 인증 및 권한 부여 방법을 이해해야 합니다. 이러한 자격 증명의 권한 있는 특성으로 인해 구현의 일부로 승인 흐름을 사용하거나 저장소에서 자격 증명을 검색하는 것을 고려해야 합니다. 구현 후에는 이벤트가 발생하기 전에 팀원의 액세스를 문서화하고 테스트하여 지연 없이 대응할 수 있는지 확인해야 합니다.
마지막으로 보안 인시던트에 대응하기 위해 특별히 생성된 사용자는 충분한 액세스를 제공하기 위해 권한이 부여되는 경우가 많습니다. 따라서 이러한 자격 증명의 사용을 제한 및 모니터링하고, 일상적인 활동에는 사용하지 않아야 합니다.
# 위협 환경 이해
## 위협 모델 개발
위협 모델을 개발함으로써 조직은 권한이 없는 사용자보다 먼저 위협을 식별하고 완화책을 마련할 수 있습니다. 위협 모델링에는 다양한 전략과 접근 방식이 있습니다. [How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) 블로그 게시물을 참조하세요. 인시던트 대응의 경우 위협 모델은 위협 행위자가 인시던트 중 사용했을 수 있는 공격 벡터를 식별하는 데 도움이 될 수 있습니다. 적시에 대응하기 위해서는 방어 대상을 파악하는 것이 중요합니다. 위협 모델링에 AWS Partner를 사용할 수도 있습니다. AWS 파트너를 검색하려면 [AWS Partner Network](https://partners.amazonaws.com/)를 사용합니다.
## 사이버 위협 인텔리전스 통합 및 사용
사이버 위협 인텔리전스는 위협 행위자의 의도, 기회 및 역량에 대한 데이터와 분석입니다. 위협 인텔리전스를 확보하고 사용하는 것은 인시던트를 조기에 탐지하고 위협 행위자 행동을 더 잘 이해하는 데 유용합니다. 사이버 위협 인텔리전스에는 IP 주소 또는 맬웨어의 파일 해시와 같은 정적 지표가 포함됩니다. 여기에는 행동 패턴, 의도 등의 개요 수준 정보도 포함됩니다. 많은 사이버 보안 벤더와 오픈 소스 리포지토리에서 위협 인텔리전스를 수집할 수 있습니다.
AWS 환경에 대한 위협 인텔리전스를 통합하고 극대화하려면 기본 제공 기능을 사용하고 자체 위협 인텔리전스 목록을 통합합니다. Amazon GuardDuty는 AWS 내부 및 타사 위협 인텔리전스 소스를 사용합니다. DNS 방화벽, AWS WAF 규칙 등의 다른 AWS 서비스도 AWS의 지능형 위협 인텔리전스 그룹으로부터 입력을 받습니다. 일부 GuardDuty 조사 결과는 적의 전술과 기법에 대한 실제 관찰 정보를 제공하는 [MITRE ATT&CK 프레임워크](https://attack.mitre.org/)에 매핑됩니다.
# 분석 및 알림을 위한 로그 선택 및 설정
보안 조사 중에 관련 로그를 검토하여 인시던트의 전체 범위와 타임라인을 기록하고 이해할 수 있어야 합니다. 관심 있는 특정 작업이 발생했음을 나타내는 알림 생성에도 로그가 필요합니다. 쿼리 및 검색 메커니즘을 선택, 활성화, 저장 및 설정하고 경보를 설정하는 것이 중요합니다. 이 섹션에서는 이러한 각 작업을 검토합니다. 자세한 내용은 [Logging strategies for security incident response](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/) AWS 블로그 게시물을 참조하세요.
# 로그 소스 선택 및 활성화
보안 조사에 앞서 관련 로그를 캡처하여 AWS 계정의 활동을 소급하여 재구성해야 합니다. AWS 계정 워크로드와 관련된 로그 소스를 선택하고 활성화합니다.
AWS CloudTrail은 AWS 서비스 활동을 캡처하는 AWS 계정에 대해 수행된 API 직접 호출을 추적하는 로깅 서비스입니다. AWS Management Console, AWS CLI 또는 AWS SDK를 사용하여 [CloudTrail의 이벤트 기록 기능을 통해 검색](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)할 수 있는 관리 이벤트의 90일 보존 기능이 기본적으로 활성화되어 있습니다. 데이터 이벤트를 더 오래 보존하고 가시성을 확보하려면 [CloudTrail 트레일을 생성](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)하고 이를 Amazon S3 버킷과 연결하고 선택적으로 Amazon CloudWatch 로그 그룹과 연결해야 합니다. 또는 최대 7년 동안 CloudTrail 로그를 유지하고 SQL 기반 쿼리 기능을 제공하는 [CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html)를 생성할 수 있습니다.
AWS는 VPC를 사용하는 고객이 각각 [VPC 흐름 로그](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) 및 [Amazon Route 53 Resolver 쿼리 로그](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html)를 사용하여 네트워크 트래픽 및 DNS 로그를 활성화하고 Amazon S3 버킷 또는 CloudWatch 로그 그룹으로 스트리밍할 것을 권장합니다. VPC, 서브넷 또는 네트워크 인터페이스에 대한 VPC 흐름 로그를 생성할 수 있습니다. VPC 흐름 로그의 경우 흐름 로그를 활성화하는 방법과 위치를 선택적으로 지정하여 비용을 절감할 수 있습니다.
AWS CloudTrail 로그, VPC 흐름 로그 및 Route 53 Resolver 쿼리 로그는 AWS에서 보안 조사를 지원하는 *기본 로깅 트라이펙터*입니다.
AWS 서비스는 Elastic Load Balancing 로그, AWS WAF 로그, AWS Config 레코더 로그, Amazon GuardDuty 조사 결과, Amazon Elastic Kubernetes Service(Amazon EKS) 감사 로그, Amazon EC2 인스턴스 운영 체제 및 애플리케이션 로그와 같은 기본 로그 트라이펙터에서 캡처하지 않는 로그를 생성할 수 있습니다. 로깅 및 모니터링 옵션의 전체 목록은 [부록 A: 클라우드 기능 정의](appendix-a-cloud-capability-definitions.md) 섹션을 참조하세요.
# 로그 스토리지 선택
로그 스토리지의 선택은 일반적으로 사용하는 쿼리 도구, 보존 기능, 친숙도 및 비용과 관련이 있습니다. AWS 서비스 로그를 활성화할 때 스토리지 시설, 일반적으로 Amazon S3 버킷 또는 CloudWatch 로그 그룹을 제공합니다.
Amazon S3 버킷은 선택적 수명 주기 정책을 통해 비용 효과적이고 내구성이 뛰어난 스토리지를 제공합니다. Amazon S3 버킷에 저장된 로그는 Amazon Athena와 같은 서비스를 사용하여 기본적으로 쿼리할 수 있습니다. CloudWatch 로그 그룹은 CloudWatch 로그 인사이트를 통해 내구성이 뛰어난 스토리지와 기본 제공 쿼리 기능을 제공합니다.
# 적절한 로그 보존 식별
S3 버킷 또는 CloudWatch 로그 그룹을 사용하여 로그를 저장하는 경우 각 로그 소스에 적절한 수명 주기를 설정하여 저장 및 검색 비용을 최적화해야 합니다. 고객은 일반적으로 3개월에서 12개월 사이의 로그를 쉽게 쿼리할 수 있으며 최대 7년 동안 보존할 수 있습니다. 가용성 및 보존에 대한 선택은 보안 요구 사항과 법적, 규제 및 비즈니스 의무의 조합과 일치해야 합니다.
# 로그에 대한 쿼리 메커니즘 선택 및 구현
AWS에서 로그를 쿼리하는 데 사용할 수 있는 주요 서비스는 CloudWatch 로그 그룹에 저장된 데이터의 경우 [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html), Amazon S3에 저장된 데이터의 경우 [Amazon Athena](https://aws.amazon.com/athena/)와 [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/)입니다. 보안 정보 및 이벤트 관리(SIEM)와 같은 타사 쿼리 도구를 사용할 수도 있습니다.
로그 쿼리 도구를 선택하는 프로세스는 보안 작업의 인력, 프로세스 및 기술 측면을 고려해야 합니다. 운영, 비즈니스 및 보안 요구 사항을 충족하고 장기적으로 액세스 및 유지 관리 가능한 도구를 선택합니다. 로그 쿼리 도구는 스캔할 로그 수가 도구의 한도 내에서 유지될 때 최적으로 작동합니다. 비용이나 기술적 제약으로 인해 고객이 여러 개의 쿼리 도구를 사용하는 경우는 드물지 않습니다. 예를 들어 지난 90일 데이터에 대한 쿼리를 수행할 때는 타사 SIEM을 사용하고, SIEM의 로그 수집 비용으로 인해 90일 이후 데이터에 대한 쿼리를 수행할 때는 Athena를 사용합니다. 구현에 관계없이, 특히 보안 이벤트 조사 중에 운영 효율성을 극대화하는 데 필요한 도구의 수를 최소화하는 접근 방식인지 확인합니다.
# 알림에 로그 사용
AWS는 기본적으로 Amazon GuardDuty, [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/), AWS Config와 같은 보안 서비스를 통해 알림을 제공합니다. 이러한 서비스에서 다루지 않는 보안 알림 또는 환경과 관련된 특정 알림에 대해 사용자 지정 알림 생성 엔진을 사용할 수도 있습니다. 이러한 알림과 탐지를 빌드하는 방법은 이 문서의 [탐지](detection.md) 섹션에서 다룹니다.
# 포렌식 기능 개발
보안 인시던트에 앞서 보안 이벤트 조사를 지원하기 위한 포렌식 기능을 개발하는 것이 좋습니다. NIST의 [Guide to Integrating Forensic Techniques into Incident Response](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-86.pdf)에서 이러한 지침을 제공합니다.
# AWS 기반 포렌식
기존 온프레미스 포렌식의 개념이 AWS에 적용됩니다. [Forensic investigation environment strategies in the AWS 클라우드](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/) 블로그 게시물은 법의학 전문 지식을 AWS로 마이그레이션하는 데 필요한 핵심 정보를 제공합니다.
포렌식을 위한 환경과 AWS 계정 구조를 설정한 후에는 네 단계에 걸쳐 포렌식 방법론을 효과적으로 수행하는 데 필요한 기술을 정의해야 합니다.
+ **수집** - AWS CloudTrail, AWS Config, VPC 흐름 로그, 호스트 수준 로그 등 관련 AWS 로그를 수집합니다. 영향을 받은 AWS 리소스의 스냅샷, 백업, 메모리 덤프를 수집합니다.
+ **검사** - 관련 정보를 추출하고 평가하여 수집한 데이터를 검사합니다.
+ **분석** - 수집된 데이터를 분석하여 인시던트를 이해하고 결론을 도출합니다.
+ **보고** - 분석 단계의 결과 정보를 제시합니다.
# 백업 및 스냅샷 캡처
주요 시스템과 데이터베이스의 백업을 설정하는 것은 보안 인시던트 복구 및 포렌식 용도로 매우 중요합니다. 백업을 설정하면 시스템을 이전의 안전한 상태로 복원할 수 있습니다. AWS에서는 다양한 리소스의 스냅샷을 생성할 수 있습니다. 스냅샷은 해당 리소스의 특정 시점 백업을 제공합니다. 백업 및 복구를 지원할 수 있는 많은 AWS 서비스가 있습니다. 백업 및 복구를 위한 이러한 서비스와 접근 방식에 대한 자세한 내용은 [Backup and Recovery Prescriptive Guidance](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/services.html)를 참조하세요. 자세한 내용은 [Use backups to recover from security incidents](https://aws.amazon.com/blogs/security/use-backups-to-recover-from-security-incidents/) 블로그 게시물을 참조하세요.
특히 랜섬웨어와 같은 상황에서는 백업의 보안을 잘 유지하는 것이 중요합니다. 백업 보안을 위한 지침은 [Top 10 security best practices for securing backups in AWS](https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-backups-in-aws/) 블로그 게시물을 참조하세요. 백업의 보안을 유지하는 것 외에도 정기적으로 백업 및 복원 프로세스를 테스트하여 보유한 기술과 프로세스가 정상적으로 작동하는지 확인해야 합니다.
# AWS 기반 포렌식 자동화
보안 이벤트가 발생하는 동안 인시던트 대응 팀은 이벤트와 관련된 기간에 정확성을 유지하면서 증거를 신속하게 수집하고 분석할 수 있어야 합니다. 클라우드 환경, 특히 많은 인스턴스와 계정에서 관련 증거를 수동으로 수집하는 작업은 인시던트 대응 팀에 어렵고 시간이 많이 소요되는 업무입니다. 또한 수작업으로 수집하는 경우 인적 오류가 발생하기 쉽습니다. 이러한 이유로 고객은 포렌식을 위한 자동화를 개발하고 구현해야 합니다.
AWS는 포렌식을 위한 다양한 자동화 리소스를 제공하며, 이는 [포렌식 리소스](appendix-b-incident-response-resources.md#forensic-resources) 아래 부록에 통합되어 있습니다. 다음은 저희가 개발하고 고객이 구현한 포렌식 패턴의 리소스 예제입니다. 시작하기에 유용한 참조 아키텍처가 될 수 있지만, 환경, 요구 사항, 도구, 포렌식 프로세스에 따라 이를 수정하거나 새로운 포렌식 자동화 패턴을 생성하는 것을 고려하세요.
# 준비 항목 요약
보안 인시던트에 대응하기 위한 철저한 준비는 시기적절하고 효과적인 인시던트 대응에 매우 중요합니다. 인시던트 대응 준비에는 사람, 프로세스, 기술이 필요합니다. 이 세 가지 영역 모두 인시던트 대응 준비에 있어 똑같이 중요합니다. 세 가지 영역 모두에 걸쳐 인시던트 대응 프로그램을 준비하고 발전시켜야 합니다.
표 2에 이 섹션에서 자세히 설명하는 준비 항목이 요약되어 있습니다.
*표 2 - 인시던트 대응 준비 항목 *
| 도메인 | 준비 항목 | 작업 항목 |
| --- | --- | --- |
| 사람 | 역할과 책임을 정의합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/preparation-summary.html) |
| 사람 | 인시던트 대응 직원에게 AWS에 대해 교육합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/preparation-summary.html) |
| 사람 | AWS 지원 옵션을 이해합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/preparation-summary.html) |
| 프로세스 | 인시던트 대응 계획을 개발합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/preparation-summary.html) |
| 프로세스 | 아키텍처 다이어그램을 문서화하고 중앙 집중화합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/preparation-summary.html) |
| 프로세스 | 인시던트 대응 플레이북을 개발합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/preparation-summary.html) |
| 프로세스 | 정기 시뮬레이션을 실행합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/preparation-summary.html) |
| 기술 | AWS 계정 구조를 개발합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/preparation-summary.html) |
| 기술 | 대응 담당자가 조사 결과에 대한 소유권과 컨텍스트를 식별하는 데 도움이 되는 태깅 전략을 개발하고 구현합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/preparation-summary.html) |
| 기술 | AWS 계정 연락처 정보를 업데이트합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/preparation-summary.html) |
| 기술 | AWS 계정에 대한 액세스를 준비합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/preparation-summary.html) |
| 기술 | 위협 환경을 이해합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/preparation-summary.html) |
| 기술 | 로그를 선택하고 설정합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/preparation-summary.html) |
| 기술 | 포렌식 기능을 개발합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/preparation-summary.html) |
인시던트 대응 준비에는 반복적인 접근 방식이 권장됩니다. 이러한 모든 준비 항목은 하루아침에 이루어질 수 없으므로 작은 것부터 시작하여 시간이 지나면서 지속적으로 인시던트 대응 능력을 향상시킬 수 있는 계획을 세워야 합니다.
# 운영
운영은 인시던트 대응 수행의 핵심입니다. 여기서 보안 인시던트 대응 및 해결 조치가 이루어집니다. 운영에는 *탐지*, *분석*, *격리*, *근절*, *복구*와 같은 다섯 가지 단계가 포함됩니다. 이러한 단계 및 목표에 대한 설명은 표 3에 나와 있습니다.
*표 3 - 운영 단계*
| Phase(단계) | 목표 |
| --- | --- |
| 탐지 | 잠재적 보안 이벤트를 파악합니다. |
| 분석 | 보안 이벤트가 인시던트인지 판단하고 인시던트 범위를 평가합니다. |
| 격리 | 보안 이벤트의 범위를 최소화하고 제한합니다. |
| 근절 | 보안 이벤트와 관련된 승인되지 않은 리소스 또는 아티팩트를 제거합니다. 보안 인시던트를 일으킨 완화 조치를 구현합니다. |
| 복구 | 시스템을 알려진 안전 상태로 복원하고 이러한 시스템을 모니터링하여 위협이 다시 발생하지 않는지 확인합니다. |
이 단계는 효과적이고 강력한 방식으로 대응하기 위해 보안 인시던트에 대응하고 이를 운영할 때 지침으로 활용해야 합니다. 실제로 취하는 조치는 인시던트에 따라 달라집니다. 예를 들어 랜섬웨어와 관련된 인시던트는 퍼블릭 Amazon S3 버킷과 관련된 인시던트와는 다른 대응 단계를 따라야 합니다. 또한 이러한 단계가 반드시 순차적으로 발생하는 것은 아닙니다. 격리 및 근절 후에는 분석 작업으로 돌아가 자신의 행동이 효과적이었는지 파악해야 할 수도 있습니다.
# 탐지
알림은 탐지 단계의 주요 구성 요소로서, 관심 있는 AWS 계정 위협 활동을 기반으로 인시던트 대응 프로세스를 시작하는 알림을 생성합니다.
알림 정확도는 까다롭습니다. 인시던트가 발생했는지, 진행 중인지 또는 향후 발생할지 항상 확실하게 확인할 수 있는 것은 아닙니다. 다음은 몇 가지 이유입니다.
+ 탐지 메커니즘은 기준 편차, 알려진 패턴 및 내부 또는 외부 엔터티의 알림을 기반으로 합니다.
+ 기술과 사람의 예측할 수 없는 특성, 즉 보안 인시던트의 *수단*과 *행위자* 때문에 기준은 시간 경과에 따라 달라집니다. 로그 패턴은 참신하거나 수정된 위협 행위자 *전술*, *기법* 및 *절차*(TTP)를 통해 나타납니다.
+ 사람, 기술 및 프로세스에 대한 변경 사항은 인시던트 대응 프로세스에 즉시 통합되지 않습니다. 일부는 조사 진행 중 발견됩니다.
# 알림 소스
다음 소스를 사용하여 알림을 정의하는 것을 고려해야 합니다.
+ ** 조사 결과** - [Amazon GuardDuty](https://aws.amazon.com/guardduty/), [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/), [Amazon Macie](https://aws.amazon.com/macie/), [Amazon Inspector](https://aws.amazon.com/inspector/), [AWS Config](https://aws.amazon.com/config/), [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html), [Network Access Analyzer](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-vaa.html) 등의 AWS 서비스는 알림을 생성하는 데 사용할 수 있는 조사 결과를 생성합니다.
+ ** 로그** - Amazon S3 버킷과 CloudWatch 로그 그룹에 저장된 AWS 서비스, 인프라 및 애플리케이션 로그를 구문 분석하고 상호 연관시켜 알림을 생성할 수 있습니다.
+ ** 결제 활동** - 결제 활동이 갑자기 변경되면 보안 이벤트가 발생할 수 있습니다. 이를 모니터링하려면 [결제 경보를 생성하여 예상 AWS 요금 모니터링](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html)에 대한 설명서를 참조하세요.
+ ** 사이버 위협 인텔리전스 **- 타사 사이버 위협 인텔리전스 피드를 구독하는 경우 해당 정보를 다른 로깅 및 모니터링 도구와 상호 연관시켜 이벤트의 잠재적 지표를 식별할 수 있습니다.
+ ** 파트너 도구** - AWS Partner Network(APN)의 파트너는 보안 목표를 달성하는 데 도움이 되는 최상위 제품을 제공합니다. 인시던트 대응의 경우 엔드포인트 탐지 및 대응(EDR) 또는 SIEM이 있는 파트너 제품은 인시던트 대응 목표를 지원하는 데 도움이 될 수 있습니다. 자세한 내용은 [보안 파트너 솔루션](https://aws.amazon.com/security/partner-solutions/)과 [Security Solutions in the AWS Marketplace](https://aws.amazon.com/marketplace/solutions/security)를 참조하세요.
+ **AWS 신뢰 및 안전** - 부적절하거나 악의적인 활동을 발견할 경우 지원에서 고객에게 연락할 수 있습니다.
+ ** 일회성 연락** - 조직 내의 고객, 개발자 또는 기타 직원이 비정상적인 상황을 발견할 수 있으므로 보안 팀에 연락할 수 있는 잘 알려져 있고 널리 알려진 방법을 마련하는 것이 중요합니다. 인기 있는 선택 사항에는 티켓팅 시스템, 담당자 이메일 주소 및 웹 양식이 포함됩니다. 조직에서 일반 대중과 함께 일하는 경우에는 대민 보안 연락 메커니즘이 필요할 수도 있습니다.
조사 중 사용할 수 있는 클라우드 기능에 대한 자세한 내용은 이 설명서의 [부록 A: 클라우드 기능 정의](appendix-a-cloud-capability-definitions.md) 섹션을 참조하세요.
# 보안 제어 엔지니어링의 일부인 탐지
탐지 메커니즘은 보안 제어 개발의 중요한 부분입니다. *지시적* 및 *예방적* 제어가 정의되면 관련 *탐지* 및 *대응* 제어를 구성해야 합니다. 예를 들어 조직에서 AWS 계정의 루트 사용자와 관련된 지시어 제어를 설정하는 경우, 이 지시어는 매우 잘 정의된 특정 활동에 대해서만 사용해야 합니다. 이를 조직의 AWS 서비스 제어 정책(SCP)을 사용하여 구현된 예방 제어와 연결합니다. 예상 기준을 초과하는 루트 사용자 활동이 발생하면 EventBridge 규칙 및 SNS 주제로 구현된 탐지 제어가 보안 운영 센터(SOC)에 알립니다. 대응 제어는 SOC가 적절한 플레이북을 선택하고, 분석을 수행하고, 인시던트가 해결될 때까지 작업하는 것을 의미합니다.
보안 제어는 AWS에서 실행되는 워크로드의 위협 모델링을 통해 가장 잘 정의됩니다. 탐지 제어의 중요도는 특정 워크로드에 대한 비즈니스 영향 분석(BIA)을 검토하여 설정됩니다. 탐지 제어에 의해 생성된 알림은 들어오는 대로 처리되지 않고 초기 중요도에 따라 분석 중 조정됩니다. 초기 중요도 세트는 우선순위를 정하는 데 도움이 됩니다. 알림이 발생한 상황에 따라 실제 중요도가 결정됩니다. 예를 들어 조직은 워크로드의 일부인 EC2 인스턴스에 사용되는 탐지 제어의 구성 요소로 Amazon GuardDuty를 사용합니다. 조사 결과 `Impact:EC2/SuspiciousDomainRequest.Reputation`이 생성되어 워크로드 내에 나열된 Amazon EC2 인스턴스가 악성으로 의심되는 도메인 이름을 쿼리하고 있음을 알려줍니다. 이 알림은 기본적으로 낮은 심각도로 설정되며, 분석 단계가 진행됨에 따라 권한이 없는 행위자가 `p4d.24xlarge` 유형의 EC2 인스턴스를 수백 개 배포하여 조직의 운영 비용을 크게 높인 것으로 확인되었습니다. 이 시점에서 인시던트 대응 팀은 이 알림의 중요도를 *높음*으로 조정하여 긴급성을 높이고 추가 조치를 신속하게 진행하기로 결정합니다. GuardDuty 조사 결과 심각도는 변경할 수 없습니다.
# 탐지 제어 구현
탐지 제어는 특정 이벤트에 대해 알림이 사용되는 방식을 결정하는 데 도움이 되므로 그 구현 방식을 이해하는 것이 중요합니다. 기술적 탐지 제어에는 두 가지 주요 구현이 있습니다.
+ **동작 탐지**는 일반적으로 기계 학습(ML) 또는 인공 지능(AI)이라고 하는 수학적 모델에 의존합니다. 탐지는 추론을 통해 이루어지므로 알림에 실제 이벤트가 반드시 반영되지는 않을 수 있습니다.
+ **규칙 기반 탐지**는 결정적입니다. 고객은 알림을 받을 활동의 정확한 파라미터를 설정할 수 있으며, 이는 확실합니다.
침입 탐지 시스템(IDS)과 같은 탐지 시스템의 최신 구현에는 일반적으로 두 메커니즘이 모두 함께 제공됩니다. 다음은 GuardDuty를 사용한 규칙 기반 및 동작 탐지의 몇 가지 예입니다.
+ `Exfiltration:IAMUser/AnomalousBehavior`라는 조사 결과가 생성될 때 이는 ‘계정에서 변칙적인 API 요청이 관찰되었음’을 알려줍니다. 설명서를 자세히 살펴보면 "ML 모델은 계정의 모든 API 요청을 평가하고 공격자가 사용하는 기법과 관련된 이상 이벤트를 식별합니다."라는 내용이 있는데,이는 이 조사 결과가 행동 특성을 가지고 있을 나타냅니다.
+ 조사 결과 `Impact:S3/MaliciousIPCaller`의 경우 GuardDuty는 CloudTrail의 Amazon S3 서비스에서 API 직접 호출을 분석하여 `SourceIPAddress` 로그 요소를 위협 인텔리전스 피드가 포함된 퍼블릭 IP 주소 테이블과 비교합니다. 항목과 직접 일치하는 항목을 찾으면 조사 결과가 생성됩니다.
위협 모델 내의 모든 활동에 대해 규칙 기반 알림을 구현하는 것이 항상 가능한 것은 아니므로 동작 기반 알림과 규칙 기반 알림을 모두 혼합하여 구현하는 것이 좋습니다.
# 사람 기반 탐지
지금까지 기술 기반 탐지에 대해 설명했습니다. 다른 중요한 탐지 소스는 고객 조직 내부 또는 외부의 사람들로부터 비롯됩니다. *내부자*는 직원 또는 계약자로 정의할 수 있으며, *외부자*는 보안 연구원, 법 집행 기관, 뉴스, 소셜 미디어와 같은 엔터티입니다.
기술 기반 탐지는 체계적으로 구성할 수 있지만 사람 기반 탐지는 이메일, 티켓, 메일, 뉴스 게시물, 전화 통화, 대면 상호 작용과 같은 다양한 형태로 제공됩니다. 기술 기반 탐지 알림은 거의 실시간으로 전달될 것으로 예상할 수 있지만 사람 기반 탐지에 대한 타임라인 기대치는 없습니다. 보안 문화에서는 보안에 대한 심층적 방어 접근 방식을 위해 사람 기반의 탐지 메커니즘을 통합하고, 촉진하고, 강화하는 것이 필수적입니다.
# 요약
탐지를 통해 규칙 기반 알림과 동작 기반 알림을 혼합하는 것이 중요합니다. 또한 내부와 외부 모두에서 보안 문제에 대한 티켓을 제출할 수 있는 메커니즘이 있어야 합니다. 인간은 보안 이벤트의 가장 중요한 소스 중 하나일 수 있으므로 사람들이 우려 사항을 에스컬레이션할 수 있도록 프로세스를 마련하는 것이 중요합니다. 환경의 위협 모델을 사용하여 탐지 구축을 시작해야 합니다. 위협 모델은 환경과 가장 관련성이 높은 위협을 기반으로 알림을 구축하는 데 도움이 됩니다. 마지막으로, 위협 행위자의 전술, 기법 및 절차(TTP)를 이해하기 위해 MITRE ATT&CK와 같은 프레임워크를 사용할 수 있습니다. MITRE ATT&CK 프레임워크는 다양한 탐지 메커니즘에서 공통 언어로 사용하는 데 유용할 수 있습니다.
# 분석
로그, 쿼리 기능 및 위협 인텔리전스는 분석 단계에 필요한 몇 가지 지원 구성 요소입니다. 탐지에 사용되는 것과 동일한 많은 로그가 분석에도 사용되며 쿼리 도구의 온보딩 및 구성이 필요합니다.
# 알림의 영향 검증, 범위 지정 및 평가
분석 단계에서는 알림을 검증하고, 범위를 정의하고, 가능한 침해의 영향을 평가하기 위해 포괄적인 로그 분석을 수행합니다.
+ 알림 *검증*은 분석 단계의 진입점입니다. 인시던트 대응 담당자는 다양한 소스에서 로그 항목을 찾고 영향을 받는 워크로드의 소유자와 직접 소통합니다.
+ *범위 지정*은 이해관계자가 오탐 가능성이 낮다는 데 동의한 후 관련된 모든 리소스를 목록화하고 알림의 중요도를 조정하는 다음 단계입니다.
+ 마지막으로 *영향 분석*은 실제 비즈니스 중단을 자세히 설명합니다.
영향을 받는 워크로드 구성 요소를 식별한 후 범위 지정 결과를 관련 워크로드의 목표 복구 시점(RPO) 및 목표 복구 시간(RTO)과 연관시켜 알림의 중요도에 맞게 조정하면 리소스 할당과 다음에 발생하는 모든 활동이 시작됩니다. 모든 인시던트가 비즈니스 프로세스를 지원하는 워크로드의 운영을 직접 방해하는 것은 아닙니다. 민감한 데이터 공개, 지적 재산 도용 또는 리소스 하이재킹(암호화 화폐 채굴 등)과 같은 인시던트는 비즈니스 프로세스를 즉시 중단하거나 약화시키지는 않지만, 나중에 결과를 초래할 수 있습니다.
# 보안 로그 및 조사 결과 강화
## 위협 인텔리전스 및 조직 컨텍스트 강화
분석 과정에서 관심 있는 관찰 항목은 알림의 컨텍스트화를 강화하기 위해 보강이 필요합니다. 준비 섹션에 설명된 대로 사이버 위협 인텔리전스를 통합하고 활용하면 보안 조사 결과를 자세히 이해하는 데 도움이 될 수 있습니다. 위협 인텔리전스 서비스는 퍼블릭 IP 주소, 도메인 이름 및 파일 해시에 평판과 속성 소유권을 할당하는 데 사용됩니다. 이러한 도구는 유료 및 무료 서비스로 제공됩니다.
Amazon Athena를 로그 쿼리 도구로 채택한 고객은 AWS Glue 작업을 활용하여 위협 인텔리전스 정보를 테이블로 로드할 수 있습니다. SQL 쿼리에서 위협 인텔리전스 테이블을 사용하여 IP 주소 및 도메인 이름과 같은 로그 요소를 상호 연관시켜 분석할 데이터를 자세히 볼 수 있습니다.
AWS는 위협 인텔리전스를 고객에게 직접 제공하지 않지만 Amazon GuardDuty와 같은 서비스는 강화 및 결과 생성을 위해 위협 인텔리전스를 사용합니다. 자체 위협 인텔리전스를 기반으로 사용자 지정 위협 목록을 GuardDuty에 업로드할 수도 있습니다.
## 자동화를 통한 강화
자동화는 AWS 클라우드 거버넌스의 필수적인 부분으로, 인시던트 대응 수명 주기의 다양한 단계에서 사용할 수 있습니다.
탐지 단계의 경우 규칙 기반 자동화는 로그에서 위협 모델의 관심 패턴을 일치시키고 알림 전송과 같은 적절한 조치를 취합니다. 분석 단계에서는 탐지 메커니즘을 활용하여 로그를 쿼리하고 이벤트 컨텍스트화를 위해 관찰 가능한 항목을 보강할 수 있는 엔진에 알림 본문을 전달할 수 있습니다.
기본 형식의 알림 본문은 *리소스*와 *ID*로 구성됩니다. 예를 들어, 알림 시점을 기준으로 알림 본문의 ID 또는 리소스가 수행한 AWS API 활동에 대해 CloudTrail을 쿼리하는 자동화를 구현하여 식별된 API 활동의 `eventSource`, `eventName`, `SourceIPAddress` 및 `userAgent`를 포함한 추가 인사이트를 제공할 수 있습니다. 이러한 쿼리를 자동화된 방식으로 수행하면 대응 담당자가 분류 중 시간을 절약하고 추가 컨텍스트를 얻어 정보에 입각한 더 나은 결정을 내릴 수 있습니다.
자동화를 사용하여 보안 조사 결과를 풍부하게 하고 분석을 단순화하는 방법에 대한 예는 [How to enrich AWS Security Hub findings with account metadata](https://aws.amazon.com/blogs/security/how-to-enrich-aws-security-hub-findings-with-account-metadata/) 블로그 게시물을 참조하세요.
# 포렌식 증거 수집 및 분석
이 문서의 [준비](preparation.md) 섹션에 언급된 포렌식은 인시던트 대응 중 아티팩트를 수집하고 분석하는 프로세스입니다. AWS에서는 네트워크 트래픽 패킷 캡처, 운영 체제 메모리 덤프 등의 인프라 영역 리소스와 AWS CloudTrail 로그 등의 서비스 영역 리소스에 적용됩니다.
포렌식 프로세스는 다음과 같은 기본적인 특징을 가지고 있습니다.
+ **일관성** - 편차 없이 문서화된 정확한 단계를 따릅니다.
+ **반복 가능성** - 동일한 아티팩트에 대해 반복할 때 정확히 동일한 결과를 생성합니다.
+ **관례성** - 공개적으로 문서화되고 널리 채택됩니다.
인시던트 대응 중 수집된 아티팩트에 대한 관리 연속성을 유지하는 것이 중요합니다. 자동화를 사용하고 이 컬렉션의 문서를 자동으로 생성하면 도움이 될 수 있으며, 아티팩트를 읽기 전용 리포지토리에 저장하는 것도 도움이 됩니다. 무결성을 유지하기 위해 수집된 아티팩트의 정확한 복제본에 대해서만 분석을 수행해야 합니다.
# 관련 아티팩트 수집
이러한 특성을 염두에 두고 영향과 범위에 대한 관련 알림과 평가를 기반으로 추가 조사 및 분석과 관련된 데이터를 수집해야 합니다. 서비스/컨트롤 플레인 로그(CloudTrail, Amazon S3 데이터 이벤트, VPC 흐름 로그), 데이터(Amazon S3 메타데이터 및 객체), 리소스(데이터베이스, Amazon EC2 인스턴스)를 포함하여 조사와 관련이 있을 수 있는 다양한 유형의 데이터와 소스입니다.
서비스/컨트롤 플레인 로그는 로컬 분석을 위해 수집하거나, 이상적으로는 기본 AWS 서비스(해당하는 경우)를 사용하여 직접 쿼리할 수 있습니다. 데이터(메타데이터 포함)를 직접 쿼리하여 관련 정보를 얻거나 소스 객체를 획득할 수 있습니다. 예를 들어 AWS CLI를 사용하여 Amazon S3 버킷 및 객체 메타데이터를 획득하고 소스 객체를 직접 획득합니다. 리소스는 리소스 유형 및 의도된 분석 방법과 일치하는 방식으로 수집해야 합니다. 예를 들어 데이터베이스를 실행하는 시스템의 복사본/스냅샷을 생성하거나, 전체 데이터베이스 자체의 복사본/스냅샷을 생성하거나, 조사와 관련된 데이터베이스에서 특정 데이터와 로그를 쿼리하고 추출하여 데이터베이스를 수집할 수 있습니다.
Amazon EC2 인스턴스의 경우 수집해야 하는 특정 데이터 세트와 분석 및 조사를 위해 가장 많은 양의 데이터를 획득하고 보존하기 위해 수행해야 하는 특정 수집 순서가 있습니다.
특히 Amazon EC2 인스턴스에서 가장 많은 양의 데이터를 획득하고 보존하기 위한 대응 순서는 다음과 같습니다.
1. **인스턴스 메타데이터 획득** - 조사 및 데이터 쿼리와 관련된 인스턴스 메타데이터(인스턴스 ID, 유형, IP 주소, VPC/서브넷 ID, 리전, Amazon Machine Image(AMI) ID, 연결된 보안 그룹, 시작 시간)를 획득합니다.
1. **인스턴스 보호 및 태그 활성화** - 종료 방지, 종료 동작을 중지(종료로 설정된 경우)로 설정, 연결된 EBS 볼륨에 대한 종료 시 삭제 속성 비활성화, 시각적 표시 및 가능한 대응 자동화에 사용하기에 적절한 태그 적용(예: 이름이 `Status`이고 값이 `Quarantine`인 태그를 적용할 때 데이터의 포렌식 획득 수행 및 인스턴스 격리)과 같은 인스턴스 보호를 활성화합니다.
1. **디스크 획득(EBS 스냅샷)** - 연결된 EBS 볼륨의 EBS 스냅샷을 획득합니다. 각 스냅샷에는 (스냅샷을 만든 시점의) 데이터를 새 EBS 볼륨에 복원하는 데 필요한 정보가 들어 있습니다. 인스턴스 저장소 볼륨을 사용하는 경우 라이브 대응/아티팩트 수집을 수행하는 단계를 참조하세요.
1. **메모리 획득** - EBS 스냅샷은 애플리케이션 또는 OS가 메모리에 저장하거나 캐시하는 데이터를 제외할 수 있는 Amazon EBS 볼륨에 기록된 데이터만 캡처하므로 시스템에서 사용 가능한 데이터를 획득하려면 적절한 타사 오픈 소스나 상용 도구를 사용하여 시스템 메모리 이미지를 획득해야 합니다.
1. **(선택 사항) 라이브 대응/아티팩트 수집 수행** - 디스크나 메모리를 다른 방법으로 확보할 수 없는 경우나 타당한 사업적 또는 운영적 이유가 있는 경우에만 시스템에서 라이브 대응을 통해 대상 데이터(디스크/메모리/로그)를 수집합니다. 이렇게 하면 중요한 시스템 데이터와 아티팩트가 수정됩니다.
1. **인스턴스 사용 중지** - Auto Scaling 그룹에서 인스턴스를 분리하고, 로드 밸런서에서 인스턴스를 등록 취소하고, 권한이 최소화되거나 없는 사전 빌드된 인스턴스 프로파일을 조정하거나 적용합니다.
1. **인스턴스 격리 **- 인스턴스와의 현재 및 향후 연결을 종료하고 방지하여 환경 내 다른 시스템 및 리소스에서 인스턴스가 효과적으로 격리되었는지 확인합니다. 자세한 내용은 본 문서의 [격리](containment.md) 섹션을 참조하세요.
1. **대응 담당자의 선택** - 상황과 목표에 따라 다음 중 하나를 선택합니다.
+ 시스템을 사용 중지하고 종료합니다(권장).
사용 가능한 증거가 확보되면 시스템을 종료하여 인스턴스가 환경에 미칠 수 있는 향후 영향에 대한 가장 효과적인 완화 조치를 확인합니다.
+ 모니터링을 위해 구성된 격리된 환경 내에서 인스턴스를 계속 실행합니다.
표준적인 접근 방식으로 권장되지는 않지만, 상황에 따라 인스턴스를 지속적으로 관찰해야 하는 경우(인스턴스에 대한 포괄적인 조사 및 분석을 수행하기 위해 추가 데이터나 지표가 필요한 경우) 인스턴스를 종료하고 인스턴스의 AMI를 생성한 다음, 인스턴스에 대한 거의 연속적인 모니터링을 용이하게 하기 위해 완전히 격리되고 계측이 구성된 샌드박스 환경 내의 전용 포렌식 계정에서 인스턴스를 다시 시작하는 것을 고려할 수 있습니다(예: VPC 흐름 로그 또는 VPC 트래픽 미러링).
**참고**
사용 가능한 휘발성(및 가치 있는) 데이터를 캡처하려면 라이브 대응 활동 또는 시스템 격리 또는 종료 전에 메모리를 캡처해야 합니다.
# 서술 개발
분석 및 조사 중 후속 단계와 최종 보고서에서 사용할 수 있도록 수행된 작업, 수행된 분석 및 식별된 정보를 문서화합니다. 이러한 서술은 간결하고 정확해야 하며, 인시던트에 대한 효과적인 이해를 확인하고 정확한 타임라인을 유지하기 위해 관련 정보가 포함되어 있는지 확인해야 합니다. 또한 핵심 인시던트 대응 팀 외부의 사람들을 참여시킬 때도 유용합니다. 다음 예를 참고하세요
****
*마케팅 및 영업 부서는 2022년 3월 15일에 민감한 데이터가 공개적으로 게시되는 것을 피하려면 암호화폐를 지불하라는 랜섬웨어 공격을 받았습니다. SOC는 2022년 2월 20일 마케팅 및 영업 부서의 Amazon RDS 데이터베이스가 공개 접근이 가능했다고 판단했습니다. SOC는 RDS 액세스 로그를 쿼리하고 웹 개발자 중 한 명인 *Major Mary*에게 속한 자격 증명 `mm03434`와 함께 2022년 2월 20일에 IP 주소 198.51.100.23이 사용되었다고 판단했습니다. SOC는 VPC 흐름 로그를 쿼리하고 동일한 날짜에 약 256MB의 데이터가 동일한 IP 주소로 송신되었다고 판단했습니다(타임스탬프 2022-02-20T15:50\$100Z). SOC는 오픈 소스 위협 인텔리전스를 통해 자격 증명이 현재 퍼블릭 리포지토리 `https[:]//example[.]com/majormary/rds-utils`에서 일반 텍스트로 사용 가능함을 확인했습니다.*
# 격리
인시던트 대응과 관련된 격리의 한 가지 정의는 보안 이벤트의 범위를 최소화하고 환경 내 무단 사용의 영향을 포함하는 보안 이벤트를 처리하는 동안 전략의 프로세스 또는 구현입니다.
격리 전략은 다양한 요인에 따라 달라지며 격리 전략, 타이밍 및 목적의 적용 측면에서 조직마다 다를 수 있습니다. [NIST SP 800-61 Computer Security Incident Handling Guide](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final)에는 다음을 포함하여 적절한 격리 전략을 결정하기 위한 몇 가지 기준이 요약되어 있습니다.
+ 리소스의 잠재적 손상 및 도난
+ 증거 보존 필요
+ 서비스 가용성(네트워크 연결, 외부 당사자에게 제공되는 서비스)
+ 전략을 구현하는 데 필요한 시간 및 리소스
+ 전략의 효율성(부분 격리 또는 전체 격리)
+ 솔루션 기간(4시간 내에 긴급 해결 방법 제거, 2주 내에 임시 해결 방법 제거, 영구 솔루션)
그러나 AWS의 서비스와 관련하여 기본 격리 단계는 다음 세 가지 범주로 나눌 수 있습니다.
+ ** 소스 격리** - 필터링 및 라우팅을 사용하여 특정 소스의 액세스를 방지합니다.
+ ** 기법 및 액세스 격리 **- 영향을 받는 리소스에 대한 무단 액세스를 방지하기 위해 액세스를 제거합니다.
+ ** 대상 격리 **- 필터링과 라우팅을 사용하여 대상 리소스에 대한 액세스를 방지합니다.
# 소스 격리
소스 격리는 특정 소스 IP 주소 또는 네트워크 범위의 리소스에 대한 액세스를 방지하기 위해 환경 내에서 필터링 또는 라우팅을 사용하고 적용하는 것입니다. AWS 서비스를 사용한 소스 격리의 예는 다음과 같습니다.
+ **보안 그룹** - Amazon EC2 인스턴스에 격리 보안 그룹을 생성하고 적용하거나 기존 보안 그룹에서 규칙을 제거하면 Amazon EC2 인스턴스 또는 AWS 리소스에 대한 무단 트래픽을 격리하는 데 도움이 될 수 있습니다. 기존 추적 연결은 보안 그룹 변경으로 인해 종료되지 않습니다. 향후 트래픽만 새 보안 그룹에 의해 효과적으로 차단됩니다. 추적한 연결과 추적하지 않은 연결에 대한 자세한 내용은 [이 Incident Response Playbook](https://github.com/aws-samples/aws-customer-playbook-framework/blob/main/docs/Ransom_Response_EC2_Linux.md) 및 [보안 그룹 연결 추적](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)을 참조하세요.
+ **정책** - IP 주소, 네트워크 범위 또는 VPC 엔드포인트로부터의 트래픽을 차단하거나 허용하도록 Amazon S3 버킷 정책을 구성할 수 있습니다. 정책을 통해 의심스러운 주소와 Amazon S3 버킷에 대한 액세스를 차단할 수 있습니다. 버킷 정책에 대한 추가 정보는 [Amazon S3 콘솔을 사용하여 버킷 정책 추가](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html)에서 확인할 수 있습니다.
+ **AWS WAF **- AWS WAF에서 웹 액세스 제어 목록(웹 ACL)을 구성하여 리소스가 대응하는 웹 요청을 세밀하게 제어할 수 있습니다. AWS WAF에 구성된 IP 세트에 IP 주소 또는 네트워크 범위를 추가하고, IP 세트에 블록과 같은 일치 조건을 적용할 수 있습니다. 이렇게 하면 발신 트래픽의 IP 주소 또는 네트워크 범위가 IP 세트 규칙에 구성된 트래픽과 일치하는 경우 리소스에 대한 웹 요청이 차단됩니다.
다음 다이어그램에서는 인시던트 대응 분석가가 Amazon EC2 인스턴스의 보안 그룹을 수정하여 특정 IP 주소로만 새 연결을 제한하는 소스 격리의 예를 볼 수 있습니다. 보안 그룹 항목에서 언급했듯이, 보안 그룹을 변경해도 기존에 추적된 연결은 종료되지 않습니다.
![\[소스 격리 예시를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/images/source-containment-example.png)
**참고**
보안 그룹과 네트워크 ACL은 Amazon Route 53에 대한 트래픽을 필터링하지 않습니다. EC2 인스턴스를 격리할 때 외부 호스트와 접촉하지 않도록 하려면 DNS 통신도 명시적으로 차단해야 합니다.
# 기법 및 액세스 격리
리소스에 액세스할 수 있는 기능과 IAM 위탁자를 제한하여 리소스의 무단 사용을 방지합니다. 여기에는 리소스에 액세스할 수 있는 IAM 위탁자의 권한 제한과 임시 보안 자격 증명 취소도 포함됩니다. AWS 서비스를 사용한 기법 및 액세스 격리의 예는 다음과 같습니다.
+ **권한 제한** - IAM 위탁자에게 할당된 권한은 [최소 권한 원칙](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)을 따라야 합니다. 그러나 활성 보안 이벤트 중에는 특정 IAM 위탁자의 대상 리소스에 대한 액세스를 더 제한해야 할 수 있습니다. 이 경우 격리될 IAM 위탁자에서 권한을 제거하여 리소스에 대한 액세스를 격리할 수 있습니다. 이 작업은 IAM 서비스를 통해 수행되며 AWS Management Console, AWS CLI 또는 AWS SDK를 사용하여 적용할 수 있습니다.
+ **키 취소** - IAM 위탁자는 IAM 액세스 키를 사용하여 리소스에 액세스하거나 관리합니다. 이 키는 AWS CLI 또는 AWS API에 대한 프로그래밍 방식 요청에 서명하는 데 사용되는 장기 정적 자격 증명이며, 접두사 *AKIA*로 시작합니다. 자세한 내용은 [IAM 식별자](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html)의 *고유 ID 접두사 이해* 섹션을 참조하세요. IAM 액세스 키가 손상된 IAM 위탁자에 대한 액세스를 격리하려면 액세스 키를 비활성화하거나 삭제합니다. 다음 사항을 명심해야 합니다.
+ 액세스 키는 비활성화 후 다시 활성화할 수 있습니다.
+ 액세스 키는 삭제 후 복구할 수 없습니다.
+ IAM 위탁자는 언제든지 최대 2개의 액세스 키를 가질 수 있습니다.
+ 액세스 키를 사용하는 사용자 또는 애플리케이션은 키가 비활성화되거나 삭제되면 액세스 권한을 잃게 됩니다.
+ **임시 보안 자격 증명 취소** - 임시 보안 자격 증명은 조직에서 AWS 리소스에 대한 액세스를 제어하는 데 사용할 수 있으며 접두사 *ASIA*로 시작합니다. 자세한 내용은 [IAM 식별자](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html)의 *고유 ID 접두사에 대한 이해* 섹션을 참조하세요. 임시 자격 증명은 일반적으로 IAM 역할에서 사용되며 수명이 제한적이므로 교체하거나 명시적으로 취소할 필요가 없습니다. 임시 보안 자격 증명 만료 전에 임시 보안 자격 증명과 관련된 보안 이벤트가 발생하는 경우 기존 임시 보안 자격 증명의 유효 권한을 변경해야 할 수 있습니다. 이 작업은 [AWS Management Console 내에서 IAM 서비스를 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html)하여 완료할 수 있습니다. 임시 보안 자격 증명은 IAM 역할이 아닌 IAM 사용자에게도 발급할 수 있지만, 이 글을 작성하는 현재로서는 AWS Management Console 내에서 IAM 사용자의 임시 보안 자격 증명을 취소할 수 있는 옵션이 없습니다. 임시 보안 자격 증명을 만든 권한이 없는 사용자가 사용자의 IAM 액세스 키를 유출한 보안 이벤트의 경우 두 가지 방법을 사용하여 임시 보안 자격 증명을 해지할 수 있습니다.
+ IAM 사용자에게 보안 토큰 발급 시간을 기반으로 액세스를 방지하는 인라인 정책을 연결합니다. 자세한 내용은 [임시 보안 자격 증명에 대한 권한 비활성화](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html)의*Denying access to temporary security credentials issued before a specific time* 섹션을 참조하세요.
+ 손상된 액세스 키를 소유한 IAM 사용자를 삭제합니다. 필요한 경우 사용자를 다시 생성합니다.
+ **AWS WAF** - 권한이 없는 사용자가 사용하는 특정 기법에는 SQL 인젝션과 크로스 사이트 스크립팅(XSS)이 포함된 요청과 같은 일반적인 악성 트래픽 패턴이 포함됩니다. AWS WAF 기본 제공 규칙 문을 사용하여 이러한 기법을 사용하는 트래픽을 일치시키고 거부하도록 AWS WAF를 구성할 수 있습니다.
다음 다이어그램은 기술 및 액세스 격리의 예를 보여줍니다. 인시던트 대응 담당자는 액세스 키를 순환하거나 IAM 정책을 제거하여 IAM 사용자가 Amazon S3 버킷에 액세스하지 못하도록 합니다.
![\[기법 및 액세스 격리 예시를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/images/technique-and-access-containment.png)
# 대상 격리
대상 격리는 대상 호스트나 리소스에 대한 액세스를 방지하기 위해 환경 내에서 필터링 또는 라우팅을 적용하는 것입니다. 경우에 따라 대상 격리에는 합법적인 리소스가 가용성을 위해 복제되는지 확인하기 위한 복원력 형태도 포함됩니다. 격리 및 격리를 위해 리소스를 이러한 형태의 복원력에서 분리해야 합니다. AWS 서비스를 사용한 대상 격리의 예는 다음과 같습니다.
+ **네트워크 ACL **- AWS 리소스가 포함된 서브넷에 구성된 네트워크 ACL에는 거부 규칙이 추가될 수 있습니다. 이러한 거부 규칙을 적용하여 특정 AWS 리소스에 대한 액세스를 방지할 수 있지만 네트워크 액세스 제어 목록(네트워크 ACL)을 적용하면 권한 부여 없이 액세스되는 리소스뿐만 아니라 서브넷의 모든 리소스에도 영향이 있습니다. 네트워크 ACL 내에 나열된 규칙은 하향식 순서로 처리되므로 대상 리소스와 서브넷에 대한 무단 트래픽을 거부하도록 기존 네트워크 ACL의 첫 번째 규칙을 구성해야 합니다. 또는 인바운드 및 아웃바운드 트래픽 모두에 대해 단일 거부 규칙을 사용해서 완전히 새로운 네트워크 ACL을 생성하고 대상 리소스가 포함된 서브넷과 연결해서 새 네트워크 ACL을 사용하여 서브넷에 액세스하지 못하도록 할 수 있습니다.
+ **종료** - 리소스를 완전히 종료하면 무단 사용의 영향을 격리하는 데 효과적일 수 있습니다. 리소스를 종료하면 비즈니스 요구 사항에 대한 합법적인 액세스가 차단되고 불안정한 법의학 데이터를 얻을 수 없게 되므로 이는 목적이 있는 결정이어야 하며 조직의 보안 정책에 따라 판단해야 합니다.
+ **격리 VPC **- 격리 VPC를 사용하여 합법적인 트래픽(예: 바이러스 백신(AV) 또는 인터넷이나 외부 관리 콘솔에 액세스해야 하는 EDR 솔루션)에 대한 액세스를 제공하면서 리소스를 효과적으로 격리할 수 있습니다. 격리 VPC는 보안 이벤트 전에 유효한 IP 주소와 포트를 허용하도록 미리 구성할 수 있으며, 활성 보안 이벤트 중에 대상 리소스를 이 격리 VPC로 즉시 이동하여 리소스를 격리하면서 인시던트 대응의 후속 단계 동안 대상 리소스에서 합법적인 트래픽을 송수신할 수 있도록 할 수 있습니다. 격리 VPC 사용의 중요한 측면은 EC2 인스턴스와 같은 리소스를 사용하기 전에 새 격리 VPC에서 종료했다가 다시 시작해야 한다는 점입니다. 기존 EC2 인스턴스는 다른 VPC 또는 다른 가용 영역으로 이동할 수 없습니다. 이렇게 하려면 [Amazon EC2 인스턴스를 다른 서브넷, 가용 영역 또는 VPC로 이동하려면 어떻게 해야 합니까?](https://aws.amazon.com/premiumsupport/knowledge-center/move-ec2-instance/)에 약술된 단계를 따르세요.
+ **Auto Scaling 그룹 및 로드 밸런서 **- Auto Scaling 그룹과 로드 밸런서에 연결된 AWS 리소스는 대상 격리 절차의 일부로 분리하고 등록 취소해야 합니다. AWS 리소스 분리 및 등록 취소는 AWS Management Console, AWS CLI 및 AWS SDK를 사용하여 수행할 수 있습니다.
다음 다이어그램에서는 승인되지 않은 호스트의 네트워크 연결 요청을 차단하기 위해 인시던트 대응 분석가가 서브넷에 네트워크 ACL을 추가하는 대상 격리의 예를 보여줍니다.
![\[대상 격리의 예를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/images/destination-containment.png)
# 요약
격리는 인시던트 대응 프로세스의 한 단계이며 수동 또는 자동일 수 있습니다. 전반적인 방지 전략은 조직의 보안 정책 및 비즈니스 요구 사항에 부합해야 하며, 제거 및 복구 전에 부정적인 영향이 최대한 효율적으로 완화되는지 확인해야 합니다.
# 근절
보안 인시던트 대응과 관련하여 제거는 계정을 알려진 안전한 상태로 되돌리기 위해 의심스럽거나 승인되지 않은 리소스를 제거하는 것입니다. 근절 전략은 조직의 비즈니스 요구 사항에 따라 달라지는 여러 요인에 따라 달라집니다.
[NIST SP 800-61 Computer Security Incident Handling Guide](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final)에서는 근절을 위한 몇 가지 단계를 제공합니다.
1. 악용된 모든 취약성을 식별하고 완화합니다.
1. 맬웨어, 부적절한 재료 및 기타 구성 요소를 제거합니다.
1. 영향을 받는 호스트가 더 많이 검색되면(예: 새로운 맬웨어 감염) 탐지 및 분석 단계를 반복하여 영향을 받는 다른 모든 호스트를 식별한 다음 해당 호스트에 대한 인시던트를 방지하고 근절합니다.
AWS 리소스의 경우 CloudWatch Logs, Amazon GuardDuty 등의 사용 가능한 로그 또는 자동화된 도구를 통해 탐지되고 분석된 이벤트를 통해 이를 더욱 세분화할 수 있습니다. 이러한 이벤트는 환경을 알려진 안전한 상태로 적절하게 복원하기 위해 수행해야 하는 문제 해결을 결정하는 기준이 되어야 합니다.
근절의 첫 번째 단계는 AWS 계정 내에서 어떤 리소스가 영향을 받았는지 파악하는 것입니다. 이는 사용 가능한 로그 데이터 소스, 리소스 및 자동 도구의 분석을 통해 이루어집니다.
+ 계정의 IAM ID에서 수행한 무단 작업을 식별합니다.
+ 계정에 대한 무단 액세스 또는 변경 사항을 식별합니다.
+ 승인되지 않은 리소스 또는 IAM 사용자의 생성을 식별합니다.
+ 무단 변경이 있는 시스템 또는 리소스를 식별합니다.
리소스 목록이 확인되면 각 리소스를 평가하여 리소스를 삭제하거나 복원할 경우 비즈니스에 미치는 영향을 결정해야 합니다. 예를 들어, 웹 서버가 비즈니스 애플리케이션을 호스팅하고 있고 이를 삭제하면 가동 중지 시간이 발생하는 경우, 영향을 받는 서버를 삭제하기 전에 검증된 안전한 백업에서 리소스를 복구하거나 깨끗한 AMI에서 시스템을 다시 시작하는 것이 좋습니다.
비즈니스 영향 분석을 완료한 후 로그 분석의 이벤트를 사용하여 계정으로 이동하여 다음과 같은 적절한 문제 해결을 수행해야 합니다.
+ 키 교체 또는 삭제 - 이 단계에서는 행위자가 계정 내에서 활동을 계속 수행할 수 있는 기능이 제거됩니다.
+ 잠재적으로 승인되지 않은 IAM 사용자 자격 증명을 교체합니다.
+ 인식할 수 없거나 승인되지 않은 리소스를 삭제합니다.
**중요**
조사를 위해 리소스를 유지해야 하는 경우 해당 리소스를 백업하는 것이 좋습니다. 예를 들어 규제, 규정 준수 또는 법적 이유로 Amazon EC2 인스턴스를 유지해야 하는 경우 인스턴스를 제거하기 전에 [Amazon EBS 스냅샷을 생성](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html)합니다.
+ 맬웨어 감염의 경우 AWS Partner 또는 다른 벤더에 문의해야 할 수 있습니다. AWS는 맬웨어 분석 또는 제거를 위한 기본 도구를 제공하지 않습니다. 그러나 Amazon EBS용 GuardDuty 맬웨어 모듈을 사용하는 경우 제공된 조사 결과에 대한 권장 사항을 사용할 수 있습니다.
식별된 영향을 받는 리소스를 근절하면 AWS는 계정에 대한 보안 검토를 수행할 것을 권장합니다. 이는 AWS Config 규칙을 사용하거나 Prowler 및 ScoutSuite와 같은 오픈 소스 솔루션을 사용하거나 다른 벤더를 통해 수행할 수 있습니다. 또한 공개(인터넷) 대면 리소스에 대한 취약성 스캔을 수행하여 잔여 위험을 평가하는 것도 고려해야 합니다.
근절은 인시던트 대응 프로세스의 한 단계이며 인시던트와 영향을 받는 리소스에 따라 수동 또는 자동일 수 있습니다. 전반적인 전략은 조직의 보안 정책 및 비즈니스 요구 사항에 부합해야 하며 부적절한 리소스 또는 구성이 제거되면 부정적인 영향이 완화되는지 확인해야 합니다.
# 복구
복구는 시스템을 알려진 안전 상태로 복원하고, 복원 전에 백업이 안전하거나 인시던트의 영향을 받지 않는지 검증하고, 복원 후 시스템이 제대로 작동하는지 테스트하고, 보안 이벤트와 관련된 취약성을 해결하는 프로세스입니다.
복구 순서는 조직의 요구 사항에 따라 다릅니다. 복구 프로세스의 일환으로 최소한 다음을 결정하기 위해 비즈니스 영향 분석을 수행해야 합니다.
+ 비즈니스 또는 종속성 우선순위
+ 복원 계획
+ 인증 및 권한 부여
NIST SP 800-61 Computer Security Incident Handling Guide에서는 시스템 복구를 위한 몇 가지 단계를 제공합니다.
+ 클린 백업에서 시스템 복원
+ 시스템으로 복원하기 전에 백업을 평가하여 감염이 없는지 확인하고 보안 이벤트의 재발을 방지하세요.
백업 메커니즘이 제대로 작동하고 데이터 무결성이 복구 시점 목표를 충족하는지 확인하기 위해 재해 복구 테스트의 일환으로 백업을 정기적으로 평가해야 합니다.
+ 가능하면 근본 원인 분석의 일부로 식별된 첫 번째 이벤트 타임스탬프 이전의 백업을 사용하세요.
+ 자동화를 사용하여 신뢰할 수 있는 소스에서 다시 배포하는 것을 포함하여 시스템을 처음부터 다시 구축합니다. 이 작업은 새로운 AWS 계정에서 수행됩니다.
+ 클린 버전으로 손상된 파일 교체
이 작업을 수행할 때는 각별히 주의해야 합니다. 복구 중인 파일이 인시던트의 영향을 받지 않고 안전한 것으로 알려져 있는지 반드시 확인해야 합니다.
+ 패치 설치
+ 암호 변경
+ 여기에는 침해되었을 수 있는 IAM 위탁자의 암호가 포함됩니다.
+ 가능하면 최소 권한 전략의 일부로 IAM 위탁자 및 페더레이션에 역할을 사용하는 것이 좋습니다.
+ 네트워크 경계 보안 강화(방화벽 규칙 세트, 경계 라우터 액세스 제어 목록).
리소스가 복구되면 파악한 내용을 수집하여 인시던트 대응 정책, 절차 및 가이드를 업데이트하는 것이 중요합니다.
요약하면 알려진 안전한 작업으로의 반환을 용이하게 하는 복구 프로세스를 구현하는 것이 중요합니다. 복구에는 오랜 시간이 걸릴 수 있으며, 비즈니스 영향과 재인증 위험의 균형을 맞추려면 격리 전략과의 밀접한 연결이 필요합니다. 복구 절차에는 리소스 및 서비스, IAM 위탁자를 복원하고 계정에 대한 보안 검토를 수행하여 잔여 위험을 평가하는 단계가 포함되어야 합니다.
# 결론
각 운영 단계에는 고유한 목표, 기법, 방법론 및 전략이 있습니다. 표 4에는 이러한 단계와 이 섹션에서 다루는 몇 가지 기법 및 방법론이 요약되어 있습니다.
* 표 4 - 운영 단계: 목표, 기법 및 방법론*
| Phase(단계) | 목표 | 기법 및 방법론 |
| --- | --- | --- |
| 탐지 | 잠재적 보안 이벤트를 파악합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/operations-conclusion.html) |
| 분석 | 보안 이벤트가 인시던트인지 판단하고 인시던트 범위를 평가하세요. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/operations-conclusion.html) |
| 격리 | 보안 이벤트의 영향을 최소화하고 제한합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/operations-conclusion.html) |
| 근절 | 보안 이벤트와 관련된 승인되지 않은 리소스 또는 아티팩트를 제거합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/operations-conclusion.html) |
| 복구 | 시스템을 알려진 정상 상태로 복원하고 이러한 시스템을 모니터링하여 위협이 다시 발생하지 않는지 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/security-ir/latest/userguide/operations-conclusion.html) |
# 인시던트 사후 활동
위협 환경은 끊임없이 변화하므로 환경을 효과적으로 보호할 수 있는 조직의 역량도 그에 못지않게 역동적으로 대처하는 것이 중요합니다. 지속적인 개선의 핵심은 발생 가능한 보안 인시던트를 효과적으로 탐지, 대응 및 조사할 수 있는 능력을 향상시키고, 발생 가능한 취약성을 줄이며, 대응 시간을 단축하고, 안전한 운영으로 돌아갈 수 있도록 인시던트 및 시뮬레이션의 결과를 반복해서 검토하는 것입니다. 다음 메커니즘은 조직이 상황에 관계없이 효과적으로 대응할 수 있는 최신 역량과 지식을 갖추고 있는지 확인하는 데 도움이 될 수 있습니다.
# 인시던트로부터 학습하기 위한 프레임워크 구축
*파악한 내용* 프레임워크와 방법론을 구현하면 인시던트 대응 능력을 개선하는 데 도움이 될 뿐만 아니라 인시던트의 재발을 방지하는 데도 도움이 됩니다. 각 인시던트에서 교훈을 얻음으로써 동일한 실수, 노출 또는 잘못된 구성을 반복하지 않도록 하여 보안 태세를 개선할 뿐만 아니라 사전에 방지 가능한 상황으로 인한 시간 손실을 최소화할 수 있습니다.
다음 사항을 높은 수준에서 설정하고 달성하는 학습한 교훈 프레임워크를 구현하는 것이 중요합니다.
+ 학습한 교훈은 언제 적용하게 되나요?
+ 학습한 교훈 과정에는 무엇이 포함되나요?
+ 학습한 교훈은 어떻게 수행되나요?
+ 누가 어떻게 이 과정에 참여하나요?
+ 개선이 필요한 부분은 어떻게 확인할 수 있나요?
+ 개선 사항을 효과적으로 추적하고 구현할 수 있도록 어떻게 해야 할까요?
이러한 개략적인 결과 외에도, 프로세스에서 최대한의 가치(실행 가능한 개선으로 이어지는 정보)를 이끌어낼 수 있도록 올바른 질문을 하는 것이 중요합니다. 다음 질문을 고려하면 학습한 교훈 토론을 시작하는 데 도움이 됩니다.
+ 어떤 인시던트였나요?
+ 인시던트가 언제 처음 확인되었나요?
+ 어떻게 식별되었나요?
+ 어떤 시스템에서 해당 활동에 대해 경고했나요?
+ 어떤 시스템, 서비스 및 데이터가 관련되어 있나요?
+ 구체적으로 어떤 일이 발생했나요?
+ 어떤 점이 잘 작동했나요?
+ 어떤 점이 잘 작동하지 않았나요?
+ 인시던트에 대응하기 위해 어떤 프로세스 또는 절차가 실패했거나 조정되지 못했나요?
+ 다음 영역에서 개선할 수 있는 사항:
+ **사람**
+ 연락이 필요한 직원이 실제로 연락이 가능했고 연락처 목록이 최신 상태였나요?
+ 인시던트에 효과적으로 대응하고 조사하는 데 필요한 교육이나 역량을 갖춘 직원이 없었나요?
+ 적절한 리소스가 준비되어 있고 이용 가능했나요?
+ **프로세스**
+ 프로세스와 절차를 준수했나요?
+ 이 (유형의) 인시던트에 대한 프로세스와 절차가 문서화되어 있고 사용 가능했나요?
+ 필요한 프로세스 및 절차가 누락되지는 않았나요?
+ 대응 담당자가 문제를 대응하는 데 필요한 정보에 적시에 액세스할 수 있었나요?
+ **기술**
+ 기존 경고 시스템이 활동을 효과적으로 식별하고 경고했나요?
+ 기존 경고 시스템을 개선해야 하나요? 아니면 이 인시던트 유형에 대해 새로운 경고 시스템을 구축해야 하나요?
+ 기존 툴링으로 인시던트를 효과적으로 조사(검색 및 분석)할 수 있었나요?
+ 이 (유형의) 인시던트를 더 빨리 식별하려면 어떻게 해야 할까요?
+ 이 (유형의) 인시던트가 재발하는 것을 방지하려면 어떻게 해야 할까요?
+ 개선 계획의 담당자는 누구이며 개선 계획이 실행되었는지 어떻게 테스트할 예정인가요?
+ 추가 모니터링/예방적 통제/프로세스를 구현하고 테스트하는 일정은 어떻게 되나요?
이 목록은 모든 것을 포함하지는 않지만, 조직 및 비즈니스 요구 사항이 무엇인지 식별하고 인시던트로부터 가장 효과적으로 학습하고 보안 태세를 지속적으로 개선하기 위해 이를 분석할 수 있는 방법을 식별하기 위한 출발점이 될 수 있습니다. 가장 중요한 것은 인시던트 대응 프로세스, 문서화 및 이해관계자 전반의 기대치에서 학습한 교훈을 표준으로 삼아 통합하는 것부터 시작하는 것입니다.
# 성공을 위한 지표 설정
지표는 인시던트 대응 기능을 효과적으로 측정, 평가 및 개선하는 데 필요합니다. 측정항목이 없으면 조직의 성과가 얼마나 좋은지 또는 나쁜지 정확하게 측정하거나 파악할 수 있는 기준이 없습니다. 운영 우수성을 위해 노력하기 위한 기대치와 기준을 설정하려는 조직에 좋은 출발점이 될 수 있는 몇 가지 인시던트 대응에 공통적인 지표가 있습니다.
# 평균 탐지 시간
*평균 탐지 시간*은 가능한 보안 인시던트를 발견하는 데 걸리는 평균 시간입니다. 특히, 이는 첫 번째 손상 지표 발생과 초기 식별 또는 알림 사이의 시간입니다.
이 지표를 사용하여 탐지 및 알림 시스템의 성능을 추적할 수 있습니다. 효과적인 탐지 및 알림 메커니즘은 가능한 보안 인시던트가 환경 내에 남아 있지 않은지 확인하기 위한 핵심 요소입니다.
평균 탐지 시간이 길수록 가능한 보안 인시던트를 식별하고 발견하기 위해 더 효과적인 알림 및 메커니즘을 추가로 구축해야 할 필요성이 커집니다. 평균 탐지 시간이 짧을수록 탐지 및 알림 메커니즘이 더 잘 작동합니다.
# 평균 승인 시간
*평균 승인 시간*은 가능한 보안 인시던트를 확인하고 우선순위를 지정하는 데 걸리는 평균 시간입니다. 구체적으로는 알림이 생성된 후 SOC 또는 인시던트 대응 담당자가 알림을 식별하고 처리 우선순위를 정하기까지의 시간을 말합니다.
이 지표를 사용하여 팀이 알림을 얼마나 잘 처리하고 우선순위를 정하고 있는지 추적할 수 있습니다. 팀이 알림을 효과적으로 식별하고 우선순위를 지정하지 못하면 대응이 지연되고 비효율적이 됩니다.
평균 승인 시간이 길수록 팀이 보안 인시던트를 신속하게 인지하고 대응 우선순위를 정할 수 있도록 적절한 인력과 교육을 받았는지 확인해야 할 필요성이 커집니다. 평균 인지 시간이 짧을수록 팀이 보안 알림에 효과적으로 대응하고 우선순위를 잘 정할 수 있음을 의미합니다.
# 평균 대응 시간
평균 대응 시간은 가능한 보안 인시던트에 대한 초기 대응을 시작하는 데 걸리는 평균 시간입니다. 구체적으로는 보안 인시던트의 최초 알림 또는 발견부터 대응을 위한 첫 번째 조치까지의 시간을 의미합니다. 이는 평균 승인 시간과 비슷하지만 상황의 간단한 인식 또는 승인과 비교하여 특정 대응 작업(예: 시스템 데이터 획득, 시스템 격리)을 측정하는 것입니다.
이 지표를 사용하여 보안 인시던트에 대응할 준비를 추적할 수 있습니다. 앞서 언급했듯이 준비는 효과적인 대응의 핵심입니다. 이 문서의 [준비](preparation.md) 섹션을 참조하세요.
평균 대응 시간이 길수록 팀이 대응 방법에 대한 교육을 제대로 받았는지 확인하여 대응 프로세스가 효과적으로 문서화되고 활용되고 있는지 확인해야 할 필요성이 커집니다. 평균 대응 시간이 짧을수록 팀이 식별된 알림에 대한 적절한 대응을 파악하고 안전한 운영으로 돌아가는 여정을 시작하는 데 필요한 대응 조치를 더 잘 수행할 수 있습니다.
# 평균 격리 시간
*평균 격리 시간*은 가능한 보안 인시던트를 격리하는 데 걸리는 평균 시간입니다. 구체적으로는 보안 인시던트의 최초 알림 또는 발견부터 공격자나 손상된 시스템이 추가적인 피해를 입지 않도록 효과적으로 대응 조치를 완료할 때까지의 시간을 의미합니다.
이 지표를 사용하여 팀이 가능한 보안 인시던트를 얼마나 잘 완화하거나 격리할 수 있는지 추적할 수 있습니다. 가능한 보안 인시던트를 빠르고 효과적으로 격리할 수 없는 경우 추가 침해 가능성에 대한 영향, 범위 및 노출이 증가합니다.
평균 대응 시간이 길어질수록 발생하는 보안 인시던트를 신속하고 효과적으로 완화하고 격리하기 위한 지식과 역량을 모두 구축해야 할 필요성이 커집니다. 평균 격리 시간이 짧을수록 팀이 식별된 위협을 완화하고 격리하는 데 필요한 조치를 더 잘 이해하고 적용하여 비즈니스에 미치는 영향, 범위 및 위험을 줄일 수 있습니다.
# 평균 복구 시간
*평균 복구 시간*은 보안 인시던트로부터 안전하게 운영할 수 있도록 완전히 복귀하는 데 걸리는 평균 시간입니다. 구체적으로는 보안 인시던트의 최초 알림 또는 발견 시점부터 인시던트의 영향을 받지 않고 비즈니스가 정상적으로 안전하게 운영될 때까지의 시간을 의미합니다.
이 지표를 사용하여 보안 인시던트 발생 후 팀이 시스템, 계정 및 환경을 안전한 운영 상태로 되돌리는 데 얼마나 효과적인지 추적할 수 있습니다. 안전한 운영으로 신속하고 효과적으로 복귀하지 못하면 보안에 영향을 미칠 뿐만 아니라 비즈니스와 운영에 미치는 영향과 비용도 증가할 수 있습니다.
평균 복구 시간이 길수록 보안 인시던트가 운영 및 비즈니스에 미치는 영향을 최소화하기 위해 팀과 환경에 적절한 메커니즘(예: 장애 조치 프로세스 및 깨끗한 시스템을 안전하게 재배포하기 위한 CI/CD 파이프라인)을 준비해야 할 필요성이 커집니다. 평균 복구 시간이 짧을수록 팀은 보안 인시던트가 운영 및 비즈니스에 미치는 영향을 최소화하는 데 더 효과적으로 대응할 수 있습니다.
# 공격자 체류 시간
*공격자 체류 시간*은 권한이 없는 사용자가 시스템 또는 환경에 액세스할 수 있는 평균 시간입니다. 이 기간은 공격자가 시스템 또는 환경에 처음 액세스한 시점부터 시작하여 최초 알림 또는 발견 시점보다 빠를 수 있다는 점을 제외하면 평균 격리 시간과 유사합니다.
이 지표를 사용하여 공격자 또는 위협이 환경에 영향을 미치는 시간, 액세스 및 기회를 줄이기 위해 시스템과 메커니즘이 모두 얼마나 잘 작동하는지 추적할 수 있습니다. 공격자 체류 시간을 줄이는 것이 팀과 비즈니스의 최우선 과제여야 합니다.
공격자의 체류 시간이 길수록 인시던트 대응 프로세스에서 개선이 필요한 부분을 파악하여 팀이 환경에서 위협이나 공격의 영향과 범위를 최소화할 수 있는 능력을 확보해야 할 필요성이 커집니다. 공격자의 체류 시간이 짧을수록 팀은 위협이나 공격자가 사용자 환경 내에 머무는 시간과 기회를 최소화하여 궁극적으로 운영과 비즈니스에 미치는 위험과 영향을 줄일 수 있습니다.
# 지표 요약
인시던트 대응을 위한 지표를 설정하고 추적하면 인시던트 대응 기능을 효과적으로 측정, 평가 및 개선할 수 있습니다. 이를 달성하기 위해 이 섹션에서 강조한 몇 가지 일반적인 인시던트 대응 지표가 있습니다. 표 5에는 이러한 지표가 요약되어 있습니다.
* 표 5 - 인시던트 대응 지표*
| 지표 | 설명 |
| --- | --- |
| 평균 탐지 시간 | 가능한 보안 인시던트를 발견하는 데 걸리는 평균 시간 |
| 평균 승인 시간 | 가능한 보안 인시던트를 승인하고 우선순위를 지정하는 데 걸리는 평균 시간 |
| 평균 대응 시간 | 가능한 보안 인시던트에 대한 초기 대응을 시작하는 데 걸리는 평균 시간 |
| 평균 격리 시간 | 가능한 보안 인시던트를 격리하는 데 걸리는 평균 시간 |
| 평균 복구 시간 | 가능한 보안 인시던트로부터 안전한 운영을 위해 완전히 복귀하는 데 걸리는 평균 시간 |
| 공격자 체류 시간 | 공격자가 시스템 또는 환경에 액세스할 수 있는 평균 시간 |
# 손상의 표시자(IOC) 사용
*손상 지표*(IOC)는 네트워크, 시스템 또는 환경에서 관찰된 아티팩트로, 높은 수준의 신뢰도로 악의적인 활동이나 보안 인시던트를 식별할 수 있습니다. IOC는 IP 주소, 도메인, TCP 플래그 또는 페이로드와 같은 네트워크 수준 아티팩트, 실행 파일, 파일 이름 및 해시, 로그 파일 항목 또는 레지스트리 항목과 같은 시스템 또는 호스트 수준 아티팩트 등의 다양한 형태로 존재할 수 있습니다. 또한 특정 위협, 공격 또는 공격자의 방법론을 나타낼 수 있는 특정 항목 또는 아티팩트(특정 파일 또는 파일 및 레지스트리 항목 세트)의 존재, 특정 순서로 수행되는 작업(특정 IP에서 시스템에 로그인한 후 특정 비정상적인 명령이 이어지는 경우) 또는 네트워크 활동(특정 도메인을 오가는 비정상적인 인바운드 또는 아웃바운드 트래픽) 등의 항목 또는 활동의 조합일 수도 있습니다.
인시던트 대응 프로그램을 반복적으로 개선하기 위해 노력할 때 탐지 및 알림을 지속적으로 구축 및 개선하고 조사의 속도와 효율성을 개선하기 위한 메커니즘으로 IOC를 수집, 관리 및 활용하는 프레임워크를 구현해야 합니다. 먼저 인시던트 대응 프로세스의 분석 및 조사 단계에 IOC의 수집 및 관리를 통합하는 것부터 시작할 수 있습니다. 프로세스의 표준 부분으로 IOC를 선제적으로 식별, 수집, 저장하면 보다 포괄적인 위협 인텔리전스 프로그램의 일환으로 데이터 리포지토리를 구축하여 기존 탐지와 알림을 개선하고, 추가 탐지 및 알림을 구축하고, 이전에 아티팩트가 발견된 위치와 시간을 식별하고, 이전에 일치하는 IOC와 관련된 조사를 수행한 방법에 대한 문서를 작성하고 참조하는 데 사용할 수 있습니다.
# 지속적인 교육 및 훈련
교육과 훈련은 진화하고 지속적인 노력이므로 목적을 가지고 추진하고 유지해야 합니다. 팀이 진화하는 기술 상태 및 위협 환경에 상응하는 인식, 지식 및 역량을 유지하고 있는지 확인하는 다양한 메커니즘이 있습니다.
한 가지 메커니즘은 팀의 목표와 운영의 표준으로 평생 교육을 도입하는 것입니다. 준비 섹션에서 언급한 대로, 인시던트 대응 담당자와 이해관계자는 AWS 내에서 발생하는 인시던트를 탐지하고 대응하고 조사하는 방법에 대한 효과적인 교육을 받아야 합니다. 하지만 교육은 ‘한 번으로 끝나는 것’이 아닙니다. 팀이 대응의 효과성과 효율성을 개선하는 데 활용할 수 있는 최신 기술 발전, 업데이트 및 개선 사항과 조사 및 분석을 개선하는 데 활용할 수 있는 데이터 추가 사항이나 업데이트 사항에 대한 인식을 유지하고 있는지 확인하기 위해 지속적으로 교육을 실시해야 합니다.
또 다른 메커니즘은 시뮬레이션이 정기적으로(예: 분기별) 수행되고 비즈니스의 특정 성과에 초점을 두고 있는지 확인하는 것입니다. 이 문서의 [정기 시뮬레이션 실행](run-regular-simulations.md) 섹션을 참조하세요.
초기 테이블탑 연습을 실시하는 것은 개선을 위한 초기 기준을 생성하는 훌륭한 방법이지만, 지속적인 개선과 현재 운영 상태를 정확하게 반영하는 최신 정보를 유지하려면 지속적인 테스트가 중요합니다. 최신의 가장 중요한 보안 상황과 가장 중요하거나 새로운 대응 역량을 테스트하고, 이를 통해 파악한 내용을 교육, 운영, 프로세스/절차에 통합하면 대응 프로세스와 프로그램 전체를 지속적으로 개선할 수 있습니다.
# 결론
클라우드 여정을 계속 진행하면서 AWS 환경에 대한 기본적인 보안 인시던트 대응 개념을 고려하는 것이 중요합니다. 사용 가능한 제어, 클라우드 기능 및 문제 해결 옵션을 결합하여 클라우드 환경의 보안을 개선할 수 있습니다. 또한 소규모로 시작하여 대응 속도를 개선하는 자동화 기능을 도입하면서 반복하여 보안 이벤트가 발생할 때 더 잘 대비할 수 있습니다.
# 기여자
다음은 이 문서의 현재 및 과거 기여자입니다.
+ Anna McAbee, Amazon Web Services의 Senior Security Solutions Architect
+ Freddy Kasprzykowski, Amazon Web Services Senior Security Consultant
+ Jason Hurst, Amazon Web Services Senior Security Engineer
+ Jonathon Poling, Amazon Web Services Principal Security Consultant
+ Josh Du Lac, Amazon Web Services Security Solutions Architecture Senior Manager
+ Paco Hope, Amazon Web Services Principal Security Engineer
+ Ryan Tick, Amazon Web Services Senior Security Engineer
+ Steve de Vera, Amazon Web Services Senior Security Engineer
# 부록 A: 클라우드 기능 정의
AWS는 200개 이상의 클라우드 서비스와 수천 개의 기능을 제공합니다. 이러한 기능 중 다수는 기본 탐지, 예방 및 대응 기능을 제공하며, 다른 기능은 맞춤형 보안 솔루션을 설계하는 데 사용할 수 있습니다. 이 섹션에는 클라우드의 인시던트 대응과 가장 관련이 있는 서비스의 하위 세트가 포함되어 있습니다.
**Topics**
+ [로깅 및 이벤트](logging-and-events.md)
+ [가시성 및 알림](visibility-and-alerting.md)
+ [자동화](automation-1.md)
+ [보안 스토리지](secure-storage.md)
+ [미래 및 사용자 지정 보안 기능](custom.md)
# 로깅 및 이벤트
[https://aws.amazon.com/cloudtrail/](https://aws.amazon.com/cloudtrail/) - AWS 계정의 거버넌스, 규정 준수, 운영 감사 및 위험 감사를 지원하는 AWS CloudTrail 서비스입니다. CloudTrail을 사용하면 AWS 서비스 전반의 작업과 관련된 계정 활동을 로깅하고, 지속적인 모니터링하고, 유지할 수 있습니다. CloudTrail은 AWS Management Console, AWS SDK, 명령줄 도구 및 기타 AWS 서비스를 통해 수행된 작업을 포함하여 AWS 계정 활동의 이벤트 기록을 제공합니다. 이 이벤트 기록은 보안 분석, 리소스 변경 추적 및 문제 해결을 간소화합니다. CloudTrail은 두 가지 유형의 AWS API 작업을 로깅합니다.
+ **CloudTrail 관리 이벤트**(컨트롤 플레인 작업이라고도 함)는 AWS 계정의 리소스에서 수행되는 관리 작업을 보여줍니다. 여기에는 Amazon S3 버킷 생성, 로깅 설정 등의 작업이 포함됩니다.
+ 데이터 플레인 작업이라고도 하는 **CloudTrail 데이터 이벤트**는 AWS 계정의 리소스에서 수행된 리소스 작업을 보여줍니다. 이러한 작업은 대량의 활동인 경우가 많습니다. 여기에는 Amazon S3 객체 수준 API 활동(예:`GetObject`, `DeleteObject` 및 `PutObject` API 작업) 및 Lambda 함수 간접 호출 활동과 같은 작업이 포함됩니다.
[https://aws.amazon.com/config/](https://aws.amazon.com/config/) – AWS Config는 고객이 AWS 리소스 구성을 평가, 감사 및 검증할 수 있도록 지원하는 서비스입니다. AWS Config는 AWS 리소스 구성을 지속적으로 모니터링하고 기록하며, 기록된 구성을 원하는 구성과 비교하여 자동으로 평가할 수 있도록 지원합니다. AWS Config를 사용하면 고객은 AWS 리소스 간 구성 및 관계의 변경 사항을 수동 또는 자동으로 검토하고, 자세한 리소스 구성 내역을 검토하고, 고객 지침에 지정된 구성에 대한 전반적인 규정 준수 여부를 확인할 수 있습니다. 이를 통해 규정 준수 감사, 보안 분석, 변경 관리 및 운영 문제 해결이 간소화됩니다.
[https://aws.amazon.com/eventbridge/](https://aws.amazon.com/eventbridge/) – Amazon EventBridge는 AWS 리소스의 변경 사항을 설명하는 시스템 이벤트 스트림을 거의 실시간으로 제공하거나 AWS CloudTrail에서 API 직접 호출이 게시되는 시점을 알려줍니다. 신속하게 설정할 수 있는 단순 규칙을 사용하여 일치하는 이벤트를 검색하고 하나 이상의 대상 함수 또는 스트림으로 이를 라우팅할 수 있습니다. EventBridge는 운영 변경 사항이 발생할 때 이를 인식하게 됩니다. EventBridge는 환경에 대응하기 위한 메시지를 전송하고 함수를 활성화하고 변경을 수행하고 상태 정보를 기록하는 등 이러한 운영 변경 사항에 대응하고 필요에 따라 시정 조치를 취할 수 있습니다. Amazon GuardDuty와 같은 일부 보안 서비스는 EventBridge 이벤트 형태로 출력을 생성합니다. 또한 많은 보안 서비스에서 출력을 Amazon S3로 전송하는 옵션을 제공합니다.
**Amazon S3 액세스 로그** - 민감한 정보가 Amazon S3 버킷에 저장되는 경우 고객은 Amazon S3 액세스 로그를 활성화하여 해당 데이터에 대한 모든 업로드, 다운로드 및 수정을 기록할 수 있습니다. 이 로그는 버킷 자체의 변경 사항(액세스 정책 및 수명 주기 정책 변경 등)을 기록하는 CloudTrail 로그와 별개로 작성되며 이에 추가됩니다. 액세스 로그 레코드는 최대한 전송하겠지만 항상 모든 레코드가 전송된다고 보장할 수는 없다는 점에 주목할 필요가 있습니다. 버킷에 대해 적절히 로깅이 구성된 대부분의 요청은 로그 레코드가 전송됩니다. 모든 서버 로깅이 제때 전송될 것이라고 보장할 수는 없습니다.
[https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) - 고객은 Amazon CloudWatch Logs를 사용하여 CloudWatch Logs 에이전트가 있는 Amazon EC2 인스턴스에서 실행되는 운영 체제, 애플리케이션 및 기타 소스에서 생성된 로그 파일을 모니터링, 저장 및 액세스할 수 있습니다. CloudWatch Logs는 AWS CloudTrail, Route 53 DNS 쿼리, VPC 흐름 로그, Lambda 함수 등의 대상이 될 수 있습니다. 그런 다음 고객은 CloudWatch Logs에서 관련 로그 데이터를 검색할 수 있습니다.
[https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) – VPC 흐름 로그를 사용하여 고객은 VPC의 네트워크 인터페이스에서 송수신되는 IP 트래픽에 대한 정보를 캡처할 수 있습니다. 흐름 로그를 활성화한 후 Amazon CloudWatch Logs와 Amazon S3로 스트리밍할 수 있습니다. VPC 흐름 로그를 사용하면 특정 트래픽이 인스턴스에 도달하지 않는 이유의 문제 해결, 지나치게 제한적인 보안 그룹 규칙 진단, 이를 보안 도구로 사용하여 EC2 인스턴스로의 트래픽을 모니터링하는 등의 다양한 태스크를 수행할 수 있습니다. 가장 강력한 필드를 얻으려면 최신 버전의 VPC 흐름 로깅을 사용하세요.
[https://aws.amazon.com/waf/](https://aws.amazon.com/waf/) - AWS WAF는 서비스에서 검사하는 모든 웹 요청의 전체 로깅을 지원합니다. 고객은 이를 Amazon S3에 저장하여 규정 준수 및 감사 요구 사항을 충족하고 디버깅 및 포렌식을 수행할 수 있습니다. 이러한 로그는 고객이 시작된 규칙과 차단된 웹 요청의 근본 원인을 파악하는 데 도움이 됩니다. 로그는 타사 SIEM 및 로그 분석 도구와 통합할 수 있습니다.
[https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html) - Route 53 Resolver 쿼리 로그를 사용하면 Amazon Virtual Private Cloud(Amazon VPC) 내의 리소스에서 수행한 모든 DNS 쿼리를 로깅할 수 있습니다. Amazon EC2 인스턴스, AWS Lambda 함수, 컨테이너 등 어떤 것이든 Amazon VPC에 있고 DNS 쿼리를 수행하면 이 기능이 이를 기록하여 애플리케이션이 어떻게 작동하는지 탐색하고 더 잘 이해할 수 있습니다.
**기타 AWS 로그** - AWS는 새로운 로깅 및 모니터링 기능을 갖춘 고객을 위해 서비스 기능을 지속적으로 릴리스합니다. 각 AWS 서비스에 사용할 수 있는 기능에 대한 자세한 내용은 공개 설명서를 참조하세요.
# 가시성 및 알림
[https://aws.amazon.com/security-incident-response/](https://aws.amazon.com/security-incident-response/) - AWS Security Incident Response은(는) 자동화된 기능과 전문가의 지원을 결합하여 조직이 수명 주기 동안 보안 이벤트를 처리할 수 있도록 지원하는 포괄적인 서비스입니다. 이 서비스는 자동화된 모니터링 및 조사 기능을 활용하여 조직 리소스를 확보하는 동시에 보안 감독을 철저히 유지하고, 보안 이벤트가 발생하면 신속한 대응 시간을 위해 이해관계자 간의 커뮤니케이션 및 조정을 가속화합니다. 이 서비스는 보안 이벤트의 준비 및 시뮬레이션, 활성 인시던트에 대한 대응, 간소화된 인시던트 후 보고 및 분석 등 여러 사용 사례를 지원하므로 조직은 모든 단계에서 보안 문제를 처리할 수 있도록 잘 대비할 수 있게 됩니다.
[https://aws.amazon.com/security-hub/](https://aws.amazon.com/security-hub/) - AWS Security Hub CSPM는 고객에게 AWS 계정 전반의 우선순위가 높은 보안 알림과 규정 준수 상태에 대한 포괄적인 보기를 제공합니다. Security Hub CSPM은 Amazon GuardDuty, Amazon Inspector, Amazon Macie, AWS Partner 솔루션 등의 AWS 서비스에서 나온 위협 조사 결과를 집계 및 정리하고 우선순위를 지정합니다. 조사 결과는 실행 가능한 그래프와 표가 포함된 통합 대시보드에 시각적으로 요약됩니다. AWS 모범 사례와 조직에서 따르는 업계 표준을 기반으로 한 자동 규정 준수 검사를 사용하여 환경을 지속적으로 모니터링할 수도 있습니다.
[https://aws.amazon.com/guardduty/](https://aws.amazon.com/guardduty/) - Amazon GuardDuty는 고객이 AWS 계정과 워크로드를 보호할 수 있도록 악의적이거나 승인되지 않은 동작을 지속적으로 모니터링하는 관리형 위협 탐지 서비스입니다. 이 서비스는 비정상적인 API 직접 호출이나 잠재적으로 승인되지 않은 배포와 같은 활동을 모니터링하여 악의적인 행위자에 의한 Amazon EC2 인스턴스, Amazon S3 버킷의 계정 또는 리소스 손상이나 정찰 가능성을 보여줍니다.
GuardDuty는 기계 학습을 사용하여 계정 및 워크로드 활동의 이상을 탐지하는 통합 위협 인텔리전스 피드를 통해 의심스러운 공격자를 식별합니다. 잠재적 위협이 탐지되면 서비스는 GuardDuty 콘솔과 CloudWatch Events에 자세한 보안 알림을 전송합니다. 따라서 알림을 실행 가능하고 간단하게 기존 이벤트 관리 및 워크플로 시스템에 통합할 수 있습니다.
GuardDuty는 또한 특정 서비스의 위협을 모니터링하기 위한 두 가지 추가 기능인 Amazon S3 보호를 위한 Amazon GuardDuty와 Amazon EKS 보호를 위한 Amazon GuardDuty를 제공합니다. Amazon S3 보호는 GuardDuty가 객체 수준 API 작업을 모니터링하도록 활성화하여 Amazon S3 버킷 내 데이터에서 잠재적인 보안 위험을 식별하는 데 도움이 됩니다. Kubernetes 보호를 통해 GuardDuty는 Amazon EKS 내에서 Kubernetes 클러스터의 의심스러운 활동 및 잠재적 손상을 탐지할 수 있습니다.
[https://aws.amazon.com/macie/](https://aws.amazon.com/macie/) - Amazon Macie는 AWS에 저장된 민감한 데이터를 자동으로 검색, 분류 및 보호하여 데이터 손실을 방지하는 데 도움이 되는 AI 기반 보안 서비스입니다. Macie는 기계 학습(ML)을 사용하여 개인 식별 정보(PII) 또는 지적 재산과 같은 민감한 데이터를 인식하고, 비즈니스 가치를 할당하고, 이 데이터가 저장되는 위치와 조직에서 사용되는 방식에 대한 가시성을 제공합니다. Amazon Macie는 데이터 액세스 활동에 이상이 있는지 지속적으로 모니터링하고 무단 액세스 또는 의도하지 않은 데이터 유출 위험을 탐지하면 알림을 제공합니다.
[https://aws.amazon.com/config/](https://aws.amazon.com/config/) - AWS Config 규칙은 리소스에 대한 기본 구성을 나타내며 AWS Config에서 기록한 대로 관련 리소스의 구성 변경 사항에 대해 평가됩니다. 대시보드에서 리소스 구성에 대해 규칙을 평가한 결과를 볼 수 있습니다. AWS Config 규칙을 사용하면 구성 관점에서 전체 규정 준수 및 위험 상태를 평가하고, 시간 경과에 따른 규정 준수 추세를 보고, 어떤 구성 변경으로 인해 리소스가 규칙을 준수하지 않게 되었는지 확인할 수 있습니다.
[https://aws.amazon.com/premiumsupport/technology/trusted-advisor/](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) - AWS Trusted Advisor는 AWS 환경을 최적화하여 비용을 절감하고, 성능을 높이고, 보안을 강화하는 데 도움이 되는 온라인 리소스입니다. Trusted Advisor는 AWS 모범 사례에 따라 리소스를 프로비저닝하는 데 도움이 되는 실시간 지침을 제공합니다. CloudWatch Events 통합을 포함한 전체 Trusted Advisor 검사 세트는 Business Support 및 Enterprise Support 플랜 고객이 사용할 수 있습니다.
[https://aws.amazon.com/cloudwatch/](https://aws.amazon.com/cloudwatch/) – Amazon CloudWatch는 AWS 클라우드 리소스 및 AWS에서 실행하는 애플리케이션을 모니터링하는 서비스입니다. CloudWatch를 사용하여 지표를 수집 및 추적하고, 로그 파일을 수집 및 모니터링하며, 경보를 설정하고, AWS 리소스 변경에 자동으로 대응할 수 있습니다. CloudWatch는 Amazon EC2 인스턴스, Amazon DynamoDB 테이블, Amazon RDS DB 인스턴스와 같은 AWS 리소스뿐만 아니라 애플리케이션 및 서비스에서 생성된 사용자 지정 지표와 애플리케이션이 생성하는 모든 로그 파일을 모니터링할 수 있습니다. Amazon CloudWatch를 사용하여 시스템 전반의 리소스 사용률, 애플리케이션 성능, 운영 상태를 파악할 수 있습니다. 상황에 대처하고 애플리케이션을 원활하게 운영하는 데 이러한 정보를 사용할 수 있습니다.
[https://aws.amazon.com/inspector/](https://aws.amazon.com/inspector/) - Amazon Inspector는 AWS에 배포된 애플리케이션의 보안 및 규정 준수를 개선하는 데 도움이 되는 자동 보안 평가 서비스입니다. Amazon Inspector는 자동으로 애플리케이션의 취약점 또는 모범 사례와의 차이를 평가합니다. 평가를 수행한 후, Amazon Inspector는 상세한 보안 평가 결과 목록을 제공하며, 이 목록은 심각도 수준에 따라 구성되어 있습니다. 이러한 조사 결과를 직접 검토하거나 Amazon Inspector 콘솔 또는 API를 통해 사용할 수 있는 세부 평가 보고서의 일부로 검토할 수 있습니다.
[https://aws.amazon.com/detective/](https://aws.amazon.com/detective/) - Amazon Detective는 AWS 리소스에서 로그 데이터를 자동으로 수집하고 기계 학습, 통계 분석 및 그래프 이론을 사용하여 연결된 데이터 세트를 구축하여 더 빠르고 효율적인 보안 조사를 수행할 수 있는 보안 서비스입니다. Detective는 VPC 흐름 로그, CloudTrail 및 GuardDuty와 같은 여러 데이터 소스의 수조 개의 이벤트를 분석할 수 있으며, 시간 경과에 따른 리소스, 사용자 및 상호 작용에 대한 통합된 대화형 보기를 자동으로 생성합니다. 이 통합 보기를 사용하면 모든 세부 정보와 컨텍스트를 한 곳에서 시각화하여 조사 결과의 기본 원인을 식별하고, 관련 기록 활동을 자세히 살펴보고, 근본 원인을 신속하게 확인할 수 있습니다.
# 자동화
[https://aws.amazon.com/lambda](https://aws.amazon.com/lambda) – AWS Lambda는 이벤트에 대한 대응으로 코드를 실행하고 자동으로 기본 컴퓨팅 리소스를 관리하는 서버리스 컴퓨팅 서비스입니다. Lambda를 사용하여 사용자 지정 로직으로 다른 AWS 서비스를 확장하거나 AWS 규모와 성능, 보안에 따라 작동하는 자체 백엔드를 만들 수 있습니다. Lambda는 고가용성 컴퓨팅 인프라에서 코드를 실행하고 컴퓨팅 리소스 관리를 수행합니다. 여기에는 서버 및 운영 체제 유지 관리, 용량 프로비저닝 및 오토 스케일링, 코드 및 보안 패치 배포, 코드 모니터링 및 로깅이 포함됩니다. 코드를 제공하기만 하면 됩니다.
[https://aws.amazon.com/step-functions/](https://aws.amazon.com/step-functions/) – AWS Step Functions는 시각적 워크플로우를 사용해 분산 애플리케이션 및 마이크로서비스의 구성 요소를 손쉽게 조정하도록 해주는 웹 서비스입니다. Step Functions는 애플리케이션의 구성 요소를 일련의 단계로 정리하고 시각화할 수 있는 그래픽 콘솔을 제공합니다. 따라서 다단계 애플리케이션을 간단하게 빌드하고 실행할 수 있습니다. Step Functions는 각 단계를 자동으로 시작하고 추적하며 오류가 발생하면 재시도하므로 애플리케이션이 순서에 따라 예상대로 실행됩니다.
Step Functions는 각 단계의 상태를 기록합니다. 따라서 무언가 잘못된 경우 빠르게 문제를 진단하고 디버깅할 수 있습니다. 코드를 작성하지 않고도 단계를 변경하고 추가할 수 있으므로 애플리케이션을 발전시키고 더 빠르게 혁신할 수 있습니다. AWS Step Functions는 AWS 서버리스의 일부로, 서버리스 애플리케이션을 위한 AWS Lambda 함수를 간단하게 오케스트레이션할 수 있습니다. Amazon EC2 및 Amazon ECS와 같은 컴퓨팅 리소스를 사용하여 마이크로서비스 오케스트레이션에 Step Functions를 사용할 수도 있습니다.
[https://aws.amazon.com/systems-manager/](https://aws.amazon.com/systems-manager/) – AWS Systems Manager는 AWS의 인프라에 대한 가시성 및 제어 기능을 제공합니다. Systems Manager는 통합된 사용자 인터페이스를 제공하므로 여러 AWS 서비스의 운영 데이터를 보고 AWS 리소스 전체에서 운영 태스크를 자동화할 수 있습니다. Systems Manager를 사용하면 애플리케이션별로 리소스를 그룹화하고, 모니터링 및 문제 해결을 위한 운영 데이터를 보고, 리소스 그룹에 대해 조치를 취할 수 있습니다. Systems Manager는 인스턴스를 정의된 상태로 유지하고, 애플리케이션 업데이트 또는 쉘 스크립트 실행과 같은 온디맨드 변경을 수행하고, 기타 자동화 및 패치 적용 태스크를 수행할 수 있습니다.
# 보안 스토리지
[https://aws.amazon.com/s3/](https://aws.amazon.com/s3/) – Amazon S3는 어디서든 원하는 양의 데이터를 저장하고 검색할 수 있도록 구축된 객체 스토리지입니다. 이는 99.999999999%의 내구성을 제공하도록 설계되었으며 모든 업계의 시장 리더가 사용하는 수백만 개의 애플리케이션에 대한 데이터를 저장합니다. Amazon S3는 포괄적인 보안을 제공하며 규제 요구 사항을 충족하는 데 도움이 되도록 설계되었습니다. 이를 통해 고객은 비용 최적화, 액세스 제어 및 규정 준수를 위해 데이터를 관리하는 데 사용하는 방법을 유연하게 선택할 수 있습니다. Amazon S3는 Amazon S3의 저장 데이터에 대해 직접 강력한 분석을 실행할 수 있는 인플레이스 쿼리 기능을 제공합니다. Amazon S3는 타사 솔루션, 시스템 통합 파트너 및 기타 AWS 서비스로 구성된 가장 큰 커뮤니티 중 하나에서 통합된 고도로 지원되는 클라우드 스토리지 서비스입니다.
[https://aws.amazon.com/s3/storage-classes/glacier/](https://aws.amazon.com/s3/storage-classes/glacier/) – Amazon Glacier는 데이터 보관 및 장기 백업을 위한 안전하고 안정적이며 극히 저렴한 클라우드 스토리지 서비스입니다. 또한 99.999999999%의 내구성을 제공하도록 설계되었으며, 포괄적인 보안을 제공하고, 규제 요구 사항을 충족하는 데 도움이 되도록 설계되었습니다. Amazon Glacier는 아카이브 저장 데이터에 대해 직접 강력한 분석을 실행할 수 있는 인플레이스 쿼리 기능을 제공합니다. 비용을 낮추면서도 다양한 검색 요구 사항에 적합하도록 Amazon Glacier는 몇 분에서 몇 시간까지 아카이브에 액세스할 수 있는 세 가지 옵션을 제공합니다.
# 미래 및 사용자 지정 보안 기능
앞서 언급한 서비스와 기능은 전체 목록이 아닙니다. AWS는 지속적으로 새로운 기능을 추가하고 있습니다. 자세한 내용은 [AWS의 새로운 소식](https://aws.amazon.com/new/) 및 [AWS 클라우드 보안](https://aws.amazon.com/security/) 페이지를 참조하세요. AWS가 기본 클라우드 서비스로 제공하는 보안 서비스 외에도, AWS 서비스를 기반으로 자체 역량을 구축하는 데 관심이 있을 수 있습니다.
계정 내에서 AWS CloudTrail, Amazon GuardDuty, Amazon Macie 등의 기본 보안 서비스 세트를 활성화하는 것이 좋지만, 로그 자산에서 추가 가치를 도출하기 위해 이러한 기능을 확장하는 것이 좋습니다. APN Security Competency 프로그램에 나열된 도구를 비롯한 다양한 파트너 도구를 사용할 수 있습니다. 로그를 검색하기 위해 쿼리를 직접 작성할 수도 있습니다. AWS에서 제공하는 다양한 관리형 서비스 덕분에 이 작업은 그 어느 때보다 쉬워졌습니다. 이 백서의 범위를 벗어나는 조사에 도움이 되는 추가 AWS 서비스로는 Amazon Athena, Amazon OpenSearch Service, Amazon Quick, Amazon Machine Learning, Amazon EMR 등이 있습니다.
# 부록 B: AWS 인시던트 대응 리소스
AWS는 고객이 인시던트 대응 기능을 개발하는 데 도움이 되는 리소스를 게시합니다. 대부분의 예시 코드와 절차는 AWS 외부 GitHub 퍼블릭 리포지토리에서 찾을 수 있습니다. 다음은 인시던트 대응을 수행하는 방법의 예를 제공하는 몇 가지 리소스입니다.
## 플레이북 리소스
+ [인시던트 대응을 위한 프레임워크 플레이북](https://github.com/aws-samples/aws-customer-playbook-framework) - 고객이 AWS 서비스 사용 시 잠재적인 공격 시나리오에 대비하여 보안 플레이북을 생성, 개발 및 통합할 수 있는 예시 프레임워크입니다.
+ [인시던트 대응 플레이북 샘플](https://github.com/aws-samples/aws-incident-response-playbooks) - AWS 고객이 직면한 일반적인 시나리오를 다루는 플레이북입니다.
+ [AWS에서 공개적으로 사용 가능한 5개의 워크샵 출시를 발표합니다](https://aws.amazon.com/blogs/security/aws-cirt-announces-the-release-of-five-publicly-available-workshops/).
## 포렌식 리소스
+ [자동 인시던트 대응 및 포렌식 프레임워크](https://github.com/awslabs/aws-automated-incident-response-and-forensics) - 이 프레임워크와 솔루션은 격리, 획득, 검사 및 분석 단계로 구성된 표준 디지털 포렌식 프로세스를 제공합니다. AWS Λ 함수를 활용하여 자동화된 반복 가능한 방식으로 인시던트 대응 프로세스를 트리거합니다. 자동화 단계를 운영하고, 아티팩트를 저장하고, 포렌식 환경을 생성하기 위한 계정 분리를 제공합니다.
+ [Amazon EC2용 자동 포렌식 오케스트레이터](https://aws.amazon.com/solutions/implementations/automated-forensics-orchestrator-for-amazon-ec2/) - 이 구현 가이드는 잠재적 보안 문제가 탐지되는 경우 포렌식 분석을 위해 EC2 인스턴스와 연결된 볼륨에서 데이터를 캡처하고 검사하는 셀프 서비스 솔루션을 제공합니다. 솔루션을 배포하기 위한 AWS CloudFormation 템플릿이 있습니다.
+ [AWS에서 포렌식 디스크 수집을 자동화하는 방법](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/) - 이 AWS 블로그에서는 잠재적 보안 인시던트의 범위와 영향을 확인하기 위해 분석을 위한 디스크 증거를 캡처하도록 자동화 워크플로를 설정하는 방법을 자세히 설명합니다. 솔루션을 배포하기 위한 AWS CloudFormation 템플릿도 포함되어 있습니다.
# Notices
고객은 본 문서의 정보를 독립적으로 평가할 책임이 있습니다. 본 문서는 (a) 정보 제공의 목적으로만 제공되고, (b) 사전 통지 없이 변경될 수 있는 현재 AWS 제품 및 관행을 나타내고, (c) AWS 및 그 계열사, 공급업체 또는 라이선스 제공자로부터 어떠한 약속이나 보증도 하지 않습니다. AWS 제품 또는 서비스는 명시적이든 묵시적이든 어떠한 종류의 보증, 진술 또는 조건 없이 '있는 그대로' 제공됩니다. 고객에 대한 AWS의 책임 및 채무는 AWS 계약에 준거합니다. 본 문서는 AWS와 고객 간의 어떠한 계약도 구성하지 않으며 이를 변경하지도 않습니다.
© 2024 Amazon Web Services, Inc. 또는 계열사. All rights reserved.