보안 사고 분석을 위한 로깅 전략

이 글은 AWS Security Blog에 게시된 게시글 (Logging strategies for security incident response)를 한국어로 번역 및 편집하였습니다.

AWS 보안 사고 대응 가이드 에 의하면 효과적인 보안 사고에 대응하려면 로그를 잘 수집해야 합니다. 적절한 로그가 수집되어 있고, 수집된 로그를 잘 쿼리할 수 있다면 더 신속하고 효율적으로 보안 사고에 대응할 수 있습니다. 다양한 소스에서 수집된 로그는 어떤 일이 발생했는지 조사하고 그 범위를 이해하는 데 활용됩니다. 로그를 잘 분석하면 보안 사고 조치 방안도 수립할 수 있습니다. 로그 수집 모범 사례에 더 알고 싶다면 서비스와 어플리케이션 로그 수집 설정과 로그, 조사 결과 및 지표 중앙 분석을 참고하세요.

이 글에서는 보안 사고 대응을 위한 효과적인 로그 수집 전략을 수립하는 법에 대해 다룹니다. 로그 수집 전략에 도움이 되는 일반적인 클라우드 애플리케이션 스택의 로그 수집 옵션, 로그 분석 옵션, 그리고 샘플 쿼리를 포함하고 있습니다. 또한 AWS는 위협 탐지를 위한 Amazon GuardDuty와 사고 분석을 위한 Amazon Detective 같은 관리형 서비스를 제공하는데, 추가 로그를 수집하거나 사용자 지정 분석을 수행하려면 본 게시글에 설명된 방법을 고려해야 합니다.

로그 수집

보안 사고에 대응하기 위해 적절한 로그를 선택하려면 먼저 AWS환경에 배포된 애플리케이션의 구성 요소와 계층으로 구성된 일반적인 클라우드 애플리케이션 스택에 대해서 파악해야 합니다. 각 구성 요소에 대해 사용 가능한 로그 소스를 설명하고 보안 사고 대응을 위해 소스별로 로그 수집을 해야 하는 이유와 로그 수집을 활성화 하는 방법, 로그 저장 옵션을 알아보겠습니다.

보안 사고 대응을 위한 로그 선택을 위해 가장 먼저 다음 질문들을 고려해야 합니다:

로그 수집에 대한 규정 준수 및 규제 요건은 무엇인가요?
- 참고: 조직과 관련된 규정 준수 표준의 로그 보존 요건과 조직의 사고 대응 전략을 준수해야 합니다.
일반적으로 어떤 AWS 서비스를 사용하나요?
어떤 AWS 서비스가 민감한 데이터에 접근하거나 포함하나요?
어떤 위협이 가장 관련 있나요?
- 참고: 클라우드 아키텍처의 위협 모델을 수행하면 이 질문의 답을 구할 때 도움이 되 수 있습니다. 자세한 내용은 위협 모델에 접근하는 법을 참고하세요.

이러한 질문을 고려하면 다음 로그 소스를 선택하는 데 도움이 되는 로깅 요구사항을 개발하는 데 도움이 될 수 있습니다.

AWS 계정 로그

AWS 계정은 AWS에 배포된 애플리케이션의 첫 번째 기본 구성 요소입니다. 계정은 AWS 리소스를 위한 컨테이너입니다. 이 계정에서 AWS 리소스를 생성하고 관리하며, 계정은 액세스 및 청구에 대한 관리 기능을 제공합니다.

AWS CloudTrail

계정 내에서 수행되는 각 작업은 API 호출입니다. 콘솔 로그인부터 AWS CloudFormation 스택의 각 리소스 배포에 이르기까지, 계정에서 발생한 일에 대한 투명성을 제공하기 위해 이벤트가 생성됩니다. AWS CloudTrail을 사용하면 지원되는 AWS 서비스 전반의 작업과 관련된 계정 활동을 기록하고, 지속적으로 모니터링하고, 보관할 수 있습니다. CloudTrail은 AWS 관리 콘솔, AWS SDK, 명령줄 도구 및 기타 AWS 서비스를 통해 수행한 작업을 포함하여 계정 활동의 이벤트 기록을 제공합니다. CloudTrail은 API 호출을 세 가지 유형의 이벤트로 기록합니다:

관리 이벤트(컨트롤 플레인 작업)은 계정의 리소스에 대해 수행된 관리 작업을 보여줍니다. 여기에는 Amazon S3 버킷 생성 및 로깅 설정과 같은 작업이 포함됩니다.
데이터 이벤트(데이터 플레인 작업)은 계정의 리소스에서 또는 리소스 내에서 수행되는 리소스 작업을 보여줍니다. 이러한 작업은 Amazon S3 객체 수준 API 활동(예: GetObject, DeleteObject 및 PutObject API 작업) 및 AWS Lambda함수 호출 활동과 같은 대용량 활동인 경우가 많습니다.
인사이트 이벤트는 계정의 비정상적인 API 호출 비율 또는 오류 비율 활동을 캡처합니다. 이러한 이벤트를 캡처하려면 트레일에서 이러한 이벤트를 사용 설정해야 하며, 이러한 이벤트는 트레일의 대상 S3 버킷에 있는 다른 폴더 접두사에 기록됩니다. 인사이트 이벤트는 이벤트 유형, 사고 기간, 관련 API, 오류 코드 및 통계 등의 정보를 제공하여 비정상적인 활동을 이해하고 효과적으로 대응하는 데 도움을 줍니다.

보안 조사의 경우, CloudTrail은 AWS 리소스의 생성, 수정, 삭제에 대한 컨텍스트를 제공합니다. 따라서 CloudTrail은 AWS 환경에서 보안 사고 대응을 위한 가장 중요한 로그 소스 중 하나입니다. CloudTrail을 설정하는 방법은 크게 세 가지가 있으며 Security Lake를 통해 CloudTrail 이벤트를 수집할 수 있습니다:

AWS CloudTrail 이벤트 기록 – CloudTrail은 기본적으로 90일간 보존되는 관리 이벤트를 사용하도록 설정되어 있으며, 콘솔, AWS CLI(명령줄 인터페이스) 또는 AWS SDK를 사용하여 CloudTrail 이벤트 기록 기능을 통해 검색할 수 있습니다. 이벤트 기록 기능 사용을 시작하기 위해 별도의 조치를 취할 필요는 없습니다.
AWS CloudTrail 트레일 – 데이터 이벤트를 더 오래 보존하고 가시성을 확보하려면 CloudTrail 트레일을 생성하여 S3 버킷과 연결하고, 선택적으로 Amazon CloudWatch 로그 그룹과 연결해야 합니다. AWS 조직을 사용하는 경우, 조직의 각 계정에 대한 이벤트를 기록하는 조직 트레일을 만들 수 있습니다. 기본적으로 트레일은 다중 리전으로 구성되므로 각 AWS 리전에서 CloudTrail 로그를 활성화할 필요가 없습니다.
AWS CloudTrail Lake – 최대 7년 동안 CloudTrail 로그를 보관하고 SQL 기반 쿼리 기능을 제공하는 CloudTrail Lake를 만들 수 있습니다. 계정에 트레일이 구성되어 있지 않아도 CloudTrail Lake를 사용할 수 있습니다.
Amazon Security Lake – Security Lake를 사용하여 관리 및 데이터 이벤트를 포함한 CloudTrail 이벤트를 수집할 수 있습니다. 이러한 이벤트는 Amazon QuickSight 또는 기타 타사 보안 정보 및 이벤트 관리(SIEM) 도구를 사용하여 추가로 분석할 수 있습니다.

AWS Config

리소스를 생성하고 수정하는 것은 계정 사용의 필수적인 부분입니다. AWS API를 호출하여 리소스 구성 변경 사항을 추적하면 리소스 수명 주기 동안의 변경 사항을 검토하는 데 도움이 됩니다. AWS Config는 계정의 AWS 리소스 구성에 대한 자세한 보기를 제공하고, 리소스 구성을 주기적으로 검사하며, API로 시작되지 않은 구성 변경 사항을 추적합니다. 여기에는 리소스가 서로 어떻게 연관되어 있는지, 과거에 어떻게 구성되었는지 등이 포함되므로 시간이 지남에 따라 구성과 관계가 어떻게 변하는지 확인할 수 있습니다.

리소스가 배포된 각 리전에서 AWS Config를 사용 설정해야 하며, AWS Config가 기록하는 리소스에 대한 세부 정보가 포함된 구성 기록 및 구성 스냅샷 파일을 수신하도록 S3 버킷을 구성해야 합니다. 그런 다음 S3의 구성 기록을 사용하여 구성 규정 준수를 검토하고 이벤트 전, 중, 후에 수행된 활동을 분석할 수 있습니다. aggregator를 설정하여 동일한 조직의 여러 계정에서 AWS 구성 리소스 추적을 중앙 집중화해야 합니다. AWS Control Tower를 사용하여 설정을 자동화할 수 있습니다.

보안 조사 중에 리소스 구성이 시간이 지남에 따라 어떻게 변경되었는지 파악하고 싶을 수 있습니다. 예를 들어, S3 버킷과 관련된 보안 이벤트 전후의 S3 버킷 정책 변경 사항을 조사하고 싶을 수 있습니다. AWS Config는 보안 이벤트 중에 수행된 활동을 추적하는 데 도움이 되는 리소스에 대한 구성 기록을 제공합니다.

운영 체제와 애플리케이션 로그

애플리케이션과의 상호 작용을 기록하려면 운영 체제(OS) 및 애플리케이션 로그, 특히 애플리케이션 개발 프레임워크에서 생성된 사용자 정의 로그를 캡처해야 합니다. OS 및 로컬 애플리케이션 로그는 Amazon EC2 인스턴스와 관련된 보안 이벤트와 관련이 있습니다. 이러한 인스턴스는 독립형, 로드 밸런서 뒤의 자동 확장 그룹에 속해 있거나 Amazon ECS 또는 Amazon EKS 클러스터를 위한 컴퓨팅 워크로드일 수 있습니다. OS 로그는 서버의 권한 사용, 프로세스, 로그인 이벤트, 디렉토리 서비스에 대한 액세스 및 파일 시스템 활동을 추적합니다. EC2 인스턴스에 대한 잠재적 침해를 분석하려면 Windows OS의 보안 이벤트 로그와 Linux 기반 OS의 시스템 로그를 검토해야 합니다.

통합 CloudWatch 에이전트를 사용하면 EC2 인스턴스 및 온프레미스 서버에서 메트릭과 로그를 수집할 수 있습니다. CloudWatch 에이전트는 로그 데이터를 CloudWatch 로그로 집계한 다음, 그림 1과 같이 장기 보존을 위해 Amazon S3로 내보내고 원하는 SIEM 도구 또는 Amazon Athena로 분석할 수 있습니다.

그림1. CloudWatch 로그를 이용한 운영체제와 애플리케이션 로그 집계

데이터베이스 로그

SQL 데이터베이스를 사용하면 트랜잭션을 기록하여 데이터베이스의 추가 또는 삭제와 같은 수정 사항을 추적할 수 있습니다. 엔진 또는 시스템 장애가 발생한 후 데이터베이스를 일관된 상태로 복원하려면 트랜잭션 로그가 필요합니다. 트랜잭션 로그는 보안을 위해 설계되었으며, 중요한 정보에 액세스하려면 추가 처리가 필요합니다. 특히 데이터베이스에 개인 식별 정보(PII), 금융 및 결제 정보, 기타 규제 대상 정보가 포함되어 있는 경우 보안 조사 중에 데이터 상호 작용을 이해하는 것이 중요합니다.

Amazon RDS를 사용하는 경우 데이터베이스 로그를 Amazon CloudWatch 로그에 게시 할 수 있습니다. NoSQL 데이터베이스의 경우 원자적 상호 작용을 추적하는 것이 유용합니다. CloudTrail에서 Amazon DynamoDB와 같은 관리형 NoSQL데이터베이스에 대한 로그를 찾을 수 있습니다. DynamoDB는 CloudTrail과 통합되어 사용자, 역할 또는 서비스가 수행한 작업의 기록을 제공합니다. 이러한 이벤트는 CloudTrail에서 데이터 이벤트로 분류됩니다.

네트워크 로그

네트워크 활동 로깅의 목적은 네트워크를 통과하는 통신에 대한 인사이트를 얻는 것입니다. 네트워크 문제 해결 또는 네트워크 내 의심되는 멀웨어 활동에 대한 포렌식 조사에 사용하는 등 다양한 이유로 이 데이터가 필요할 수 있습니다.

AWS 클라우드에서는 네트워크 트래픽을 기록하는 프록시를 생성하거나 트래픽 미러링을 사용하여 네트워크 트래픽의 사본을 로깅 서버로 전송하여 네트워크 활동을 기록할 수 있습니다. 클라우드 네이티브 접근 방식을 채택하여 Amazon Route 53 DNS 쿼리 로그 및 Amazon VPC Flow 로그를 사용하여 이러한 유형의 데이터를 캡처할 수 있습니다.

또한 Palo Alto Networks 및 Fortinet과 같은 다양한 타사 네트워킹 솔루션을 사용할 수 있음으로 온프레미스 환경에서 사용하던 네트워크 로깅 메커니즘을 계속 사용할 수 있습니다.

Route 53 DNS 쿼리 로그

DNS쿼리를 기록하도록 Amazon Route 53을 구성 할 수 있습니다. 이러한 로그는 두 그룹으로 분류됩니다:

퍼블릭 DNS 쿼리 로깅
Resolver 쿼리 로깅

Route 53에서 호스팅한 도메인에 대한 공개 DNS 쿼리를 로깅하면 요청된 도메인 또는 하위 도메인, 요청 날짜 및 타임스탬프, DNS 레코드 유형, 응답한 Route53 Edge Location, 응답 코드와 같은 쿼리 정보가 제공됩니다.

Amazon Route 53 Resolver는 기본적으로 Amazon VPC와 함께 제공됩니다. Resolver 쿼리 로그를 캡처하면 퍼블릭 쿼리와 동일한 정보 뿐만 아니라 쿼리가 발생한 리소스의 인스턴스 ID와 같은 추가 정보도 제공됩니다. 다양한 유형의 쿼리에 대해 Resolver 쿼리 로그를 캡처할 수도 있습니다.

VPC Flow 로그

인스턴스나 제품을 추가하지 않고도 계정의 VPC에 대한 VPC 플로우 로그를 구성하여 VPC 네트워크에 들어오고 이동하는 트래픽을 캡처할 수 있습니다. 이러한 로그에서 소스 및 대상 IP, 포트, 타임스탬프, 프로토콜, 계정 ID, 트래픽이 수락되었는지 또는 거부되었는지 여부 등의 정보를 검토할 수 있습니다. 플로우 로그 기록에 사용할 수 있는 전체 필드 목록은 사용 가능한 필드를 참고하세요. VPC, 서브넷 또는 네트워크 인터페이스에 대한 플로우 로그를 만들 수 있습니다. 서브넷 또는 VPC에 대한 플로우 로그를 만들면 해당 서브넷 또는 VPC의 각 네트워크 인터페이스에서 오고 가는 IP 트래픽이 기록됩니다. VPC 플로우 로그에 대한 자세한 내용은 VPC Flow 로그를 사용하여 IP 트래픽 로깅하기를 참고하세요.

VPC FLow 로그를 Amazon CloudWatch 로그로 전달하여 메트릭 필터를 기반으로 CloudWatch 알람을 만들 수 있습니다. 장기 보존 및 추가 분석을 위해 플로우 로그를 S3 버킷으로 전달할 수도 있습니다. 그림 2는 이러한 구성을 보여줍니다.

그림 2. CloudWatch 로그와 S3에 VPC Flow 로그 보내기

액세스 로그

액세스 가능한 엔드포인트, 특히 공용 엔드포인트의 액세스 패턴을 식별하려면 액세스 로그를 사용해야 합니다. 액세스 로그는 로드 밸런서에 전송된 요청에 대한 자세한 정보를 캡처합니다. 각 로그에는 요청이 수신된 시간, 클라이언트의 IP 주소, 지연 시간, 요청 경로, 서버 응답 등의 정보가 포함됩니다. 로드 밸런서 뒤에 계층적으로 서비스를 구축하고 사용 중이라면, 요청자의 컨텍스트를 확인하기 위해서는 X-Forwarded-For 리퀘스트 헤더를 추적해야 합니다. 액세스 로그는 조사 및 분석 중에 이러한 격차를 해소하는 데 도움이 됩니다.

Amazon S3 서버 액세스 로그

액세스 로그는 기밀 또는 민감한 데이터를 저장하기 위해 S3 버킷을 사용할 때 개체 수준 액세스를 추적하는 데 매우 중요합니다. CloudTrail을 활성화하여 S3 데이터 이벤트를 캡처할 수 있고, 액세스 로그를 S3 버킷에 저장하여 규정 준수를 위한 장기 보관과 이벤트 발생 중 및 발생 후 분석을 실행할 수 있습니다.

로드 밸런싱 로그

Elastic Load Balancing은 로드 밸런서에 전송된 요청에 대한 자세한 정보를 캡처하는 액세스 로그를 제공합니다. 각 로그에는 요청이 수신된 시간, 클라이언트의 IP 주소, 지연 시간, 요청 경로, 서버 응답 등의 정보가 포함됩니다. 이 로그를 사용하여 트래픽 패턴을 분석하고 문제를 해결할 수 있습니다.

액세스 로그는 기본적으로 비활성화 되어 있는 Elastic Load Balancing의 선택적 기능입니다. 로드 밸런서에 대한 액세스 로그를 활성화 하려면 애플리케이션 로드 밸런서에 대한 액세스 로그를 참조하세요.

로드 밸런싱을 할 때 요구사항에 따라 자체 리버스 프록시를 구현하는 경우, 리버스 프록시 액세스 로그를 캡처해야 합니다. 통합 CloudWatch 에이전트를 사용하여 해당 로그를 CloudWatch로 전달할 수 있습니다. OS 로그와 마찬가지로, 장기 보존 및 분석을 위해 CloudWatch 로그를 S3 버킷으로 내보낼 수 있습니다.

최종 사용자를 위한 공용 엔드포인트로 Amazon CloudFront를 사용하고 로드 밸런서가 사용자 지정 origin인 경우, 로드 밸런싱 액세스 로그는 실제 최종 사용자가 아닌 CloudFront 배포를 요청자로 표시합니다. 이 정보가 사고 처리 과정에 유용하지 않다면 최종 사용자 요청 세부 정보를 제공하는 로그 소스로 CloudFront 액세스 로그를 사용할 수 있습니다.

CloudFront 액세스 로그

CloudFront를 사용할 때는 표준 로그(액세스 로그)를 활성화해야 합니다. CloudFront가 파일을 저장할 S3 버킷을 지정합니다.

CloudFront 액세스 로그는 최대한 빠르고 정확하게 전달됩니다. 배포에 대한 요청에 대한 정보를 실시간으로 확인하려면 요청을 받은 후 몇 초 이내에 제공되는 실시간 로그를 사용하면 됩니다. 실시간 로그를 사용하여 콘텐츠 전송 성능을 모니터링, 분석하고 이를 기반으로 조치를 취해야 합니다. 이러한 로그에서 사용할 수 있는 필드에 대한 자세한 내용은 CloudFront 표준 로그 파일 형식을 참고하세요.

AWS WAF 로그

CloudFront 배포, Amazon API Gateway REST API, Application Load Balancer, AWS AppSync GraphQL API, Amazon Cognito 사용자 풀 또는 AWS App Runner와 같이 AWS WAF가 지원하는 리소스와 연결 시 AWS WAF가 리소스로 전달되는 HTTP 및 HTTPS 요청을 모니터링하는 데 도움을 줄 수 있습니다. 요청을 세밀하게 제어할 수 있도록 웹 액세스 제어 목록(ACL)을 구성하고, 이러한 ACL에 대한 로깅을 활성화하여 AWS WAF에서 분석하는 트래픽에 대한 자세한 정보를 얻어야 합니다. 로그 정보에는 요청이 AWS 리소스로부터 AWS WAF에 수신된 시간, 요청에 대한 세부 정보, 요청이 일치하는 AWS WAF 규칙이 포함됩니다. 이 로그 정보를 사용하여 퍼블릭 엔드포인트의 액세스 패턴을 모니터링하고 요청을 자세히 검사하는 규칙을 구성할 수 있습니다. AWS WAF 로깅에 대한 자세한 내용은 web ACL 트래픽 로깅을 참고하세요.

서버리스 로그

서버리스 컴퓨팅은 클라우드 컴퓨팅 공간에서 점점 더 인기를 얻고 있습니다. 서버리스 컴퓨팅은 비교적 짧은 시간에 온디맨드 컴퓨팅 성능을 제공하므로 처리해야 할 작업이 없을 때 클라우드 기반 인스턴스를 프로비저닝하고 유휴 상태로 유지할 필요가 없습니다. 점점 더 많은 컴퓨팅 작업이 서버리스 솔루션으로 이전되는 와중에도 로깅은 여전히 중요하지만 로그를 생성하는 방식은 변했습니다. 서버리스 환경에서 효과적인 보안 조사를 하기 위해서는 배포된 코드의 상호 작용과 변경 사항을 보여주는 로그 뿐만 아니라 배포된 코드 자체의 변경 사항과 권한 있는 액세스를 부여하는 Lambda 실행 역할의 액세스 권한도 로깅하는 게 유용합니다.

AWS Lambda

Lambda 함수의 로깅에는 함수 자체의 작동 방식과 함수 내부에서 일어나는 일 (코드가 실제로 수행하는 작업) 이라는 두 가지 요소가 포함됩니다.

Lambda 함수 자체의 로깅은 CloudTrail에서 캡처한 데이터 이벤트를 통해 이루어집니다. 이 글의 앞부분에서 언급했듯이, CloudTrail에서 생성한 트레일에서 데이터 이벤트를 구성해야 합니다. 구성하는 동안 트레일에서 로그를 캡처할 함수와 로그를 저장할 대상 S3 버킷을 지정해야 합니다. 이러한 로그에는 함수 호출에 대한 세부 정보가 포함되어 있으며, Lambda용 Invoke API를 호출한 IAM 주체를 식별하는 데 도움이 됩니다.

AWS Lambda는 사용자를 대신하여 Lambda 함수를 자동으로 모니터링하고 로그를 CloudWatch로 전송합니다. Lambda 함수는 CloudWatch 로그 그룹과 함수의 각 인스턴스에 대한 로그 스트림과 함께 제공됩니다. Lambda 런타임 환경은 각 호출에 대한 세부 정보를 로그 스트림으로 전송하고, 함수 코드의 로그 및 기타 출력을 중계합니다. Lambda 함수를 모니터링하는 방법에 대한 자세한 내용은 AWS Lambda용 Amazon CloudWatch 로그에 액세스하기를 참조하세요.

로그 분석

사고 대응을 위해서는 로그를 분석하고 쿼리하여 발생한 내용을 검증하고 범위를 파악할 수 있어야 합니다.

우선 다양한 소스의 로그를 S3 버킷에 집계하여 장기 보관하고, 해당 데이터를 쿼리 도구와 통합하여 추가 조사를 수행할 수 있습니다. 로그를 내보내서 직접 구문 분석하거나 다른 도구로 수집하여 분석에 도움을 받을 수 있습니다. 다음은 이러한 로그를 쿼리하는 데 사용할 수 있는 몇 가지 옵션입니다.

Amazon Athena – 로그 파일의 위치를 지정하는 SQL 명령을 사용하여 Athena를 통해 S3에 저장된 CloudTrail 이벤트를 직접 쿼리할 수 있습니다. 일반적으로 실행할 고급 쿼리가 있고 SIEM이 없는 경우 이 방법을 사용합니다. 로그를 쿼리하도록 Athena를 설정하려면 AWS의 오픈 소스 솔루션을 사용할 수 있습니다.
Amazon OpenSearch Service – OpenSearch는 분산 검색 및 로그 분석 제품군입니다. 오픈 소스이기 때문에 AWS 로그 소스뿐만 아니라 그 이상의 로그 소스에서 로그를 수집할 수 있습니다. 이를 설정하려면 AWS의 오픈 소스 SIEM 솔루션을 사용할 수 있습니다.
CloudTrail이벤트 기록 – 콘솔에서 또는 프로그래밍 방식으로 지난 90일 동안의 CloudTrail 관리 이벤트를 쿼리할 수 있습니다. 지난 90일 이내에 간단한 쿼리를 수행해야 하고 저장된 로그나 더 복잡한 쿼리가 필요하지 않은 경우에 이상적입니다.
AWS CloudTrail Lake – 콘솔에서 또는 프로그래밍 방식으로 구성된 CloudTrail Lake에 저장된 이벤트를 구성 시점부터 쿼리 시점으로부터 최대 저장 기간인 2,557일(7년)까지 쿼리할 수 있습니다. 이 접근 방식은 SQL 기반 쿼리를 허용하며, 이벤트에 대해 보다 복잡한 쿼리를 수행해야 하지만 SIEM 솔루션의 추가 기능이 필요하지 않은 경우에 이상적입니다.
CLI를 사용한 원시 JSON 구문 분석 – 프로그래밍 방식으로 수행하며 터미널 명령을 통해 구문 분석합니다. 이는 로그를 구문 분석하는 레거시 방식에 가깝습니다. 다른 서비스나 솔루션을 사용할 수 없는 경우 (예: 회사 보안 정책으로 인해 해당 서비스를 사용할 수 없는 경우) 이 방법을 분석에 사용할 수 있습니다.
타사 SIEM – AWS 또는 다른 곳에 이미 SIEM 솔루션이 있고 다른 곳에 중복된 솔루션이 필요하지 않은 경우 타사 SIEM이 이상적일 수 있습니다. 일반적으로 SIEM 솔루션은 S3 버킷에서 로그를 가져와서 분석을 위해 이벤트를 처리하고 색인 합니다. SIEM 옵션에 대해 자세히 알아보려면 AWS Marketplace의 SIEM 솔루션을 참조하거나, 위협 탐지 및 사고 대응(TDIR) 전문성을 갖춘 현지 파트너를 찾으려면 AWS Security Competency Partners를 참조하세요.

샘플 쿼리

이 섹션에서는 SQL 쿼리 샘플을 살펴봅니다. Athena와 CloudTrail Lake는 모두 SQL 쿼리를 허용하지만, 본 게시물에서 소개하는 샘플은 Athena에서의 사용만 테스트 되었습니다. 일부 쿼리가 VPC Flow로그를 위한 것이고 CloudTrail Lake에서는 쿼리가 불가능하기 때문입니다. Athena에서 CloudTrail 로그를 쿼리하려면 먼저 S3에 저장된 로그의 위치를 가리키는 테이블 정의를 만들어야 합니다. 이 작업은 CloudTrail 이벤트 콘솔에서 하이퍼링크된 제안을 사용하거나 Athena 콘솔에서 직접 수행할 수 있습니다. 또는, Athena의 경우 AWS Security Analytics Bootstrap을 사용할 수 있습니다.

각 쿼리에 대해서, 조사 중인 기간, 관련된 IAM 엔티티, 범위 내 계정 및 지역과 같은 일부 필드를 수정해야 할 수도 있습니다. 예를 들어, 현재 시간과 보안 이벤트가 시작된 시점을 기준으로 시간 프레임을 수정해야 할 수 있습니다. 이 경우 추가 쿼리를 실행하고 범위와 타임라인에 대해 자세히 알아본 후 기간을 확장하는 경우가 많습니다.

테이블에 파티션을 사용하면 각 Athena 쿼리에서 스캔하는 데이터의 양을 제한하여 성능을 개선하고 비용을 절감할 수 있습니다. 수동으로 또는 파티션 프로젝션을 사용하여 CloudTrail Athena 테이블을 파티션할 수 있습니다. 쿼리에 파티션 열(예: 타임스탬프)을 포함시키면 스캔하는 데이터의 양을 제한할 수 있습니다.

승인되지 않은 시도

보안 이벤트가 발생하면 IAM 주체에 의해 시도되었지만, IAM 주체에 해당 리소스에 대해 작업을 수행할 수 있는 액세스 권한이 없기 때문에 실패한 API 호출을 검토할 수 있습니다. 이 활동을 확인하려면 다음 쿼리를 실행하세요. (테스트 시 이벤트타임 범위를 적절히 수정해야 합니다):

SELECT *
FROM cloudtrail
WHERE errorcode IN ('Client.UnauthorizedOperation','Client.InvalidPermission.NotFound','Client.OperationNotPermitted','AccessDenied')
AND useridentity.arn LIKE '%iam%'
AND eventtime >= '2023-01-01T00:00:00Z'
AND eventtime < '2023-03-01T00:00:00Z'
ORDER BY eventtime desc

이 샘플 쿼리는 특정 IAM 주체가 무단 API 호출을 많이 하는지 여부를 식별하는 데 도움이 될 수 있으며, 이는 IAM 주체가 공격 당했음을 나타낼 수 있습니다.

거부된 TCP 연결

포렌식 후속 조치 또는 위험 분석 후 검색 작업의 일환으로 이전 버전의 TLS 프로토콜을 사용하여 AWS API를 얼마나 많이 호출했는지 확인하고 싶을 수 있습니다. 이 데이터는 CloudTrail 로그를 쿼리하여 얻을 수 있습니다.

SELECT eventSource
COUNT(*) AS numOutdatedTlsCalls FROM cloudtrail WHERE tlsDetails.tlsVersion IN ('TLSv1', 'TLSv1.1') AND eventTime > '2023-01-01 00:00:00' GROUP BY eventSource ORDER BY numOutdatedTlsCalls DESC

IP에서 연결 필터링

조사하려는 IP 주소가 있는 경우 포렌식 분석의 일부로 VPC의 리소스에 대한 연결을 확인하고 싶을 수 있습니다. 이 정보는 VPC 플로우 로그를 쿼리하여 얻을 수 있습니다. 서버 액세스 로그와 마찬가지로, Athena를 사용하는 경우 먼저 새 테이블 만들기가 필요합니다.

SELECT day_of_week(date) AS 
day, date, srcaddr, dstaddr, action, protocol
FROM vpc_flow_logs
WHERE day >= '2023/01/01' AND day < '2023/03/01' AND srcaddr LIKE '172.50.%'
ORDER BY day DESC
LIMIT 100

사용자 행동 조사

유출되었거나 유출된 것으로 의심되는 사용자를 식별한 경우, 특정 기간 동안 해당 사용자가 수행한 API 호출을 알고 싶을 수 있습니다. 사용자의 활동을 이해하면 사고 발생 시 영향의 범위와 액세스 관리 전략을 설계할 때 사용자 권한의 범위를 이해하는 데 도움이 될 수 있습니다.

SELECT eventID, eventName, eventSource, eventTime, userIdentity.arn
AS user
FROM cloudtrail
WHERE userIdentity.arn = '%<username>%' AND eventTime > '2022-12-05 00:00:00' AND eventTime < '2022-12-08 00:00:00'

결론

애플리케이션 스택의 다양한 계층에서 발생하는 보안 이벤트에 효과적으로 대응하려면 애플리케이션 아키텍처 내의 다양한 계층에서 로그를 수집해야 합니다. 로그를 통해 보안 이벤트 발생 시 사고 상황과 영향을 받은 리소스의 범위를 명확하게 파악할 수 있습니다. 본 게시물은 분석할 로그, 해당 로그를 저장할 위치, 분석 방법에 대한 이해를 통해 보안 사고 대응을 위한 로깅 전략 수립에 도움을 드리기 위해 작성되었습니다.

추가 리소스

본 게시물에 대한 피드백은 아래 코멘트에 작성하실 수 있습니다. 본 게시물에 대한 질문이 있다면 AWS Security, Identity, & Compliance re:Post에서 새 스레드를 시작하거나 AWS Support에 문의하세요.

AWS 기술 블로그