클라우드의 경우
- 각 AWS 계정의 CloudTrail log를 CloudWatch Logs로 전송
- CloudWatch Logs에 log stream이 전송되면, 트리거로 Lambda 함수를 호출 하면서, parameter값으로 cloudtrail log를 전달
- 호출된 Lambda 함수는 cloudtrail log를 argument로 해서, ElasticSearch의 JSON 포맷에 맞춰 parsing
- 여러개의 계정에서 수집되고 parsing된 cloudtrail log는 하나의 ElasticSearch로 HTTPS를 사용하여 전송
- 수집된 cloudtrail log를 분석하여 탐지를 실행 ,,
(아직 Lambda 파트는 이해가 안된거 같다.)
웹의 경우 vpc flowlog랑 elb log 활용예정이다
무튼 오늘 복습할 내용은 Cloud Trail 이다. 프로젝트와 관련된 내용도 조금 기술하고, 기본적으로 알아야 할 특징들,
몰랐던 내용위주로 쓰려고 한다.
기본적으로, 이번 프로젝트를 진행함에 있어 가장 잘 활용해야 하는 것이 바로 cloud trail 이다.
왜냐? 우리가 ISMS-P 인증 기준을 따라 최종적으로 사용자가 침해사고대응 보고서를 획득할 수 있도록 하는 것이 핵심이기 때문.
ISMS-P란 "정보통신망의 안정성 확보 및 개인정보 보호를 위해 조직이 수립한 일련의 조치와 활동이 인증기준에 적합함을 인증기관이 평가하여 인증을 부여하는 제도" 인데 쉽게 말해서 그냥 우리 정보 잘 지키고 있어요 기준이다.
침해사고 발생 일시, 보고자, 보고일시, 사고내용(발견사항, 피해내용 등), 사고내용 경과 내용, 사고대응까지의 소요시간
등을 보고서에 담아야 하는데,
계정들의 로그들을 이녀석이 기록하고 있기 때문.
이벤트를 기록하는 방법은 3가지가 있는데,
1. Event history (이벤트 기록) - 계정 만들면 자동으로 생성. 90일간 검색 및 다운로드 가능. 무료. 단일 aws 계정 제한, 단일 리젼. s3 데이터 이벤트 표시 x
2. CloudTrail AWS CloudTrail Lake - 사용한 만큼 요금 지불.
- 중앙 집중식 로그 저장소:
- CloudTrail Lake는 여러 AWS 계정과 리전에서 발생하는 모든 이벤트 로그를 중앙에 저장
- SQL 기반 로그 분석:
- CloudTrail Lake는 SQL 기반의 쿼리 언어를 사용하여 로그 데이터를 실시간으로 검색하고 분석가능
- 복잡한 쿼리를 작성하여 특정 이벤트를 쉽게 찾아낼 수 있다.
- 자동 데이터 수집 및 저장:
- CloudTrail Lake는 모든 이벤트 로그를 자동으로 수집하고 저장.
- 설정된 보존 기간 동안 로그 데이터를 중앙에 저장하여 관리.
3. Trails (추적)
- 로그 수집 및 저장:
- Trails는 AWS 계정에서 발생하는 API 호출 및 이벤트 로그를 수집하고 지정된 S3 버킷에 저장.
- 각 이벤트가 발생할 때마다 로그 파일이 생성되고 저장.
- 관리 이벤트 및 데이터 이벤트:
- 관리 이벤트: AWS 리소스에 대한 관리 작업(예: 생성, 수정, 삭제)과 관련된 이벤트를 기록.
- 데이터 이벤트: S3 객체 레벨 작업(예: PutObject, GetObject) 및 Lambda 함수의 호출과 같은 데이터 작업을 기록합니다.
- 글로벌 및 다중 리전 설정:
- Trails는 글로벌 이벤트와 다중 리전 이벤트를 지원하여, 모든 리전에서 발생하는 이벤트를 하나의 트레일에 수집할 수 있다.
- S3 및 CloudWatch Logs와 통합:
- 로그 데이터를 S3 버킷에 저장하고, CloudWatch Logs로 전송하여 실시간 모니터링과 알림을 설정할 수 있습니다.
AWS CloudTrail Trails VS AWS CloudTrail Lake
로그 수집 및 저장 | S3 버킷에 로그 저장 | 중앙 집중식 로그 저장소 |
로그 분석 방법 | Athena, S3 Select, CloudWatch Logs Insights 사용 | SQL 기반의 쿼리 언어를 통한 실시간 분석 |
데이터 보존 기간 | 설정한 기간 동안 S3에 저장 | 최대 7년간 중앙에서 보존 |
데이터 접근 | S3, CloudWatch Logs를 통한 접근 | 중앙 집중식 접근 및 세분화된 접근 제어 |
사용 사례 | 기본적인 로그 수집 및 저장, 규정 준수 | 중앙 집중식 관리, 실시간 분석, 장기 보존 및 보안 |
이벤트 기반 처리 | SNS, CloudWatch Events를 통한 알림 설정 | EventBridge와 통합된 자동 대응 |
비용 효율성 | S3 저장 비용 및 분석 도구 사용 비용 | 중앙 저장소 및 장기 보존을 통한 비용 절감 |
일단 지금 lake는 사용하지 않고 있다. ex) 로그인 여러번 실패 - Console Login 이벤트 기준으로 한다고 했을때 수집한 로그들을 백앤드 연산으로 처리할 예정이라고는 가정해놓긴 했는데, 이부분 처리가 만약에 안된다고 하면 Lake 사용해야 할 듯 싶다. EX) 특정 사용자에 대한 모든 이벤트 검색, 특정 기간 동안의 Console Login 이벤트 검색, 특정 소스 IP에서 발생한 모든 이벤트 검색,,,
ConsoleLogin 이벤트의 성공 및 실패 횟수 계산
SELECT responseElements.ConsoleLogin, COUNT(*)
FROM $EDS_ID
WHERE eventName = 'ConsoleLogin'
GROUP BY responseElements.ConsoleLogin
'Project > AWS 침해사고대응' 카테고리의 다른 글
CERT 업무 - 침해 사고 분류 & 대응 (0) | 2024.07.23 |
---|---|
추가 개념 공부 - 로드밸런서 (2) | 2024.07.22 |
AWS 서비스 이해 - WAF (0) | 2024.07.22 |
AWS 서비스 이해 - Cloud Trail (2) (0) | 2024.07.18 |
프롤로그 (0) | 2024.07.11 |