SecOps 개념

Security 와 Operations 가 합쳐진 개념으로, 조직의 인프라 운영에 보안을 통합하는 것을 기반으로 함

보안팀과 운영팀이 협력과 소통 문화를 조성하여 시스템을 지속 감시하고, 위협을 탐지하며, 침해사고에 대응하는 체계

효율적인 보안환경을 구축하는게 중요 → Automation, Security Orchestration

SecOps Workflow(AWS 기준)

📝 SecOps 로그 소스(AWS)

🔴 CloudTrail

로그 개요

AWS 콘솔, CLI, SDK, 다른 AWS 서비스를 통해 이루어진 API 활동과, 일부 비 API 활동의 이력을 이벤트로 기록

확인 가능한 행위

누가 작업을 수행했는가
언제 작업이 발생했는가
어느 IP 주소와 리전에서 요청했는가
어떤 AWS 서비스와 API를 호출했는가
어떤 리소스를 대상으로 작업했는가
요청이 성공했는가 또는 실패했는가

이벤트에 기록되는 정보(핵심 필드)

기본 출력 형식은 JSON


"eventTime": "2026-08-05T15:30:12Z", // 이벤트 발생 시간 (UTC)
"eventSource": "iam.amazonaws.com",  // 호출된 AWS 서비스(IAM, EC2, S3)
"eventName": "CreateAccessKey",  // 실행된 API
"awsRegion": "ap-northeast-2",  // 요청이 처리된 Region
"sourceIPAddress":"58.235.187.29", // 요청 출발지 IP
"userAgent": "aws-cli/2.36.15", // 요청에 사용된 도구(콘솔, CLI, SDK)
"userIdentity": { // 작업을 수행한 주체
	"type": "IAMUser",
	"userName": "developer",
	"accessKeyId": "EXAMPLE" // 작업에 사용된 액세스 키
},
"requestParameters": {  // API 요청 내용
	"userName": "backup-svc" // 키를 발급받는 IAM 사용자
},
"responseElements": {
	"accessKey": { "accessKeyId": "NEWKEY" } // 새로 생성된 키
},
"readOnly": false, // 쓰기 작업 여부
"eventCategory": "Management", // 이벤트 유형
"eventID": "eae87c48-d421-4626-94f5-..." // 이벤트 고유 ID, SIEM에서 이벤트 중복 제거・고유 식별 키로 활용

=> developer 이 backup-svc IAM 사용자에게 액세스 키를 발급

4가지의 이벤트 유형을 기록

Management Event - 로그인・권한변경・자원 생성・변경・삭제 행위 기록(기본 활성화)

예시) 공격 단계별 이벤트(노출된 액세스 키로 인한 S3 데이터 유출)

단계	서비스	이벤트	의미	공격 연관성
초기 접근・ 자격증명 획득	STS	`AssumeRole`	역할 전환	권한 상승 가능성
내부 정찰	IAM	`GetAccountAuthorizationDetails`	계정 내 IAM 구조 전수 조회	권한 상승 경로 탐색
권한 상승	IAM	`CreatePolicyVersion`	정책 새 버전 생성	`Action:*` 버전으로 관리자급 권한 획득
지속성 확보	IAM	`CreateAccessKey`	액세스 키 생성	백도어 자격증명 발급
방어 회피	CloudTrail	`StopLogging`	로깅 중지	공격자의 행위 로그 공백
실질적 피해	S3	`PutBucketPolicy`	버킷 정책 변경	버킷 Public공개

Data Event - 중요 S3 버킷 데이터의 경우 별도 기능 활성화 필요(비용 발생)

리소스 안의 실제 데이터나 워크로드에 접근한 행위를 기록

관리 이벤트에서 나아가 실제 데이터 유출이 발생하는 이벤트를 보여줌

예시) S3 데이터 유출

단계	서비스	이벤트	의미	공격 연관성
데이터 정찰	S3	`ListObjects`	버킷 내 객체 목록 조회	탈취 대상 파일 탐색
데이터 유출	S3	`GetObject`	객체 읽기	데이터 유출
증거 인멸	S3	`DeleteObject`	객체 삭제	유출 후 흔적 제거
데이터 변조	S3	`PutObject`	객체 업로드	악성파일 삽입, 덮어쓰기
서버리스 실행	Lambda	`Invoke`	함수 호출	무단 함수 실행을 통한 내부 접근

Network Activity Event - VPC Endpoint로 접근한 AWS API 분석 필요 시 활성화(비용 발생)

VPC Endpoint를 경유하는 API 행위 기록

VPC 내부에서 수행된 리소스 작업에 대한 가시성 제공

예시 이벤트

단계	서비스	이벤트	의미	공격 연관성
데이터 경계 침해 시도	S3	`GetObject`+ `errorCode:VpceAccessDenied`	Endpoint 정책에 의해 거부	외부 계정의 자격증명으로 내부 데이터 접근 시도
내부 정찰	S3	`ListBucket`	버킷 목록 조회	VPC 내부에서의 자산 탐색
자격증명 탈취시도	Secrets Manager	`GetSecretValue`	시크릿 값 조회	내부 경로를 통한 자격 증명 획득
암호화 우회시도	KMS	`Decrypt`	복호화 요청	암호화된 데이터 접근 시도

Insights Event - 기존 활동 대비 이상 활동 분석 필요 시 활성화(비용 발생)

기존 관리 이벤트 등의 활동량을 분석해 이상 활동이 감지될 경우 이벤트 생성

무차별 API 호출과 같은 이상 API 활동 기록

기준선 대비 통계적 이상 탐지

InsightType	탐지 대상	공격 연관성
`ApiCallRateInsight`	특정 API 호출 빈도 급증/급감	대량 삭제, 대량 조회, 리소스 대량 생성
`ApiErrorRateInsight`	특정 API 오류율 급증	권한 정찰, 무차별 시도

CloudTrail 이벤트 이해 - AWS CloudTrail

사용자, 역할 또는 AWS 서비스 계정이 수행한 작업 기록을 가져옵니다 AWS CloudTrail.

https://docs.aws.amazon.com/ko_kr/awscloudtrail/latest/userguide/cloudtrail-events.html

로그 수집・저장 방법

Event History - CloudTrail이 기본적으로 제공하는 서비스로, 관리 이벤트만 조회 가능(최근 90일, 리전 단위)

S3 저장 - 로그를 장기 보존할 수 있고, 침해사고 발생 시 포렌식에 활용

추적 생성을 통해 지정한 S3 버킷으로 로그를 지속적으로 전달

CloudWatch - 로그 검색, Metric 필터, 알람 기능 제공

추적 생성 후, CloudWatch Logs 로그 그룹과 IAM Role 을 연결하여 연동
AWS CloudTrailCloudWatch Logs에 이벤트 전송 - AWS CloudTrail
CloudWatch Logs에 이벤트 전송 - AWS CloudTrail
사용자, 역할 또는 AWS 서비스 계정이 수행한 작업 기록을 가져옵니다 AWS CloudTrail.
AWS CloudTrail

CloudTrail Lake - SQL 기반으로 직접 조회 및 포렌식 가능

SIEM 연동 - 일반적인 SecOps 환경에서 활용

👉

일반적으로 S3와 CloudWatch 를 함께 사용(역할 구분)

S3 - 원본 로그 보존, 감사・포렌식・재수집

CloudWatch - Log Insights・경보・SIEM 전달

탐지 가능한 위협 - “eventName” 필드만 작성 - 탐지룰 작성 시에는 “eventSource” 매핑도 필요

계정 및 자격증명 탈취

관련 이벤트 로그


"eventName":{
	"ConsoleLogin", // AWS Management Console 로그인 시도(eventSource: signin)
	"AssumeRole", // IAM 역할을 맡아 임시 자격증명 발급
	"CreateAccessKey", // 신규 액세스 키 생성
	"UpdateAccessKey", // 액세스 키 상태 변경
	"GetSessionToken" // 장기 자격증명으로 임시 세션 토큰 발급
}

권한 상승

관련 이벤트 로그 - IAM 권한 부여・변경을 통해 권한 상승 발생


"eventName":{
	"AttachUserPolicy", // 사용자에게 관리형 정책 연결
	"AttachRolePolicy", // 역할에 관리형 정책 연결
	"PutUserPolicy", // 사용자에게 인라인 정책 부여
	"PutRolePolicy", // 역할에 인라인 정책 부여
	"CreatePolicyVersion", // 기존 정책의 새 버전 생성
	"SetDefaultPolicyVersion", // 정책의 기본 버전 지정
	"UpdateAssumeRolePolicy", // 역할의 신뢰 정책 변경
	"AddUserToGroup"  // 사용자를 그룹에 추가
}

지속성 확보

관련 이벤트 로그 - 백도어 생성


"eventName":{
	"CreateUser", // 신규 IAM User 생성
	"CreateAccessKey", // 액세스 키 생성
	"CreateLoginProfile", // 콘솔 로그인 비밀번호 설정/생성
	"CreateRole", // 신규 IAM Role 생성
	"UpdateAssumeRolePolicy" // 역할의 신뢰 정책 변경
}

보안 그룹 위험 설정

관련 이벤트 로그 - “requestParameters” 필드와 같이 분석


"eventName":{
	"AuthorizeSecurityGroupIngress", // 인바운드 허용 규칙 추가
	"ModifySecurityGroupRules", // 기존 규칙의 내용 변경
}

감사 및 보안 서비스 무력화

관련 이벤트 로그 - 공격 흔적을 숨기는 행위(방어 회피)


"eventName":{
	"StopLogging", // 추적(Trail) 로깅 중지
	"DeleteTrail", // 추적 자체를 삭제
	"UpdateTrail", // 추적 설정 변경
	"DeleteEventDataStore", // 이벤트 데이터 스토어 삭제(장기보관 로그 제거)
	"DeleteDetector", // 탐지기 삭제
	"DisableSecurityHub", // SecurityHub 비활성화
	"StopConfigurationRecorder" // 리소스 변경 기록 중지
}

비인가 리전 사용

관련 이벤트 로그


"eventName":{
	"RunInstances", // EC2 인스턴스 생성
	"CreateFunction", // Lambda 함수 생성
	"CreateCluster", // 클러스터 생성(eventSource: ecs, eks)
	"CreateDBInstance" // 데이터베이스 인스턴스 생성
}

리소스 파괴 및 서비스 영향

관련 이벤트 로그


"eventName":{
	"TerminateInstances", // EC2 인스턴스 종료
	"DeleteDBInstance", // DB 인스턴스 삭제
	"DeleteBucket", // S3 버킷 삭제
	"DeleteSnapshot", // EBS 스냅샷 삭제
	"ScheduleKeyDeletion", // KMS 키 삭제 예약
	"DisableKey", // KMS 키 비활성화
	"DeleteRecoveryPoint" // AWS Backup 복구 지점 삭제
}

S3 데이터 접근 및 유출

관련 이벤트 로그 - Data Event 활성화한 경우 탐지


"eventName":{
	"GetObject", // 객체 읽기(다운로드)
	"PutObject", // 객체 업로드/덮어쓰기
	"DeleteObject", // 객체 1개 삭제
	"DeleteObjects" // 객체 다수 일괄 삭제(최대 1,000개/요청)
}

권한 탐색 및 API 스캔

관련 이벤트 로그 - userAgent, 대상 서비스 및 호출 빈도를 함께 분석


"errorCode": "AccessDenied" // API 호출 실패 시 생성되는 필드

/* Insights Events 활성화 시, AccessDenied 등 API 오류 발생률이
기존 기준선보다 비정상적으로 증가한 패턴을 탐지할 수 있음 */

CloudTrail 한계

AWS 계정 활동과 API 호출을 기록하지만, 리소스 내부의 행위나 네트워크 패킷은 기록 못함

VPC Flow Logs, WAF Logs, DNS Query Log 와 연계 필요

→ CloudWatch, SIEM 에서 상관분석

이벤트 발생 순서가 보장되지 않고, 중복 레코드가 포함될 수 있음

“eventTime” 을 기준으로 정렬 필요
“eventID” 를 문서 식별자로 사용해 중복 제거

로그가 비동기적으로 전달되어 지연 발생(일반 이벤트는 평균 약 5분 후 전달)

탐지룰 구성 시, 지연 평가 적용

기본 활성 범위가 Management Event 로 제한

Data Event, Network Activity Event는 별도 활성화 필요 → 비용 발생

CloudTrail 이 방어회피(StopLogging 등)에 의해 무력화 될 수 있음

해당 Trail 목적지에 로그 공백 발생
사전 차단 : SCP 로 관련 거부
피해 최소화 : 중단 전 별도 사본 확보

🟠 VPC Flow Logs

로그 개요

VPC 내 네트워크 인터페이스를 오가는 IP 트래픽의 메타데이터 기록(Payload는 못 봄)

Flow Logs 활성화 단위

단위	수집 범위
VPC	VPC 내 모든 ENI
Subnet	해당 서브넷의 모든 ENI
ENI	특정 인터페이스 하나

확인 가능한 행위

어떤 출발지 IP 가 어떤 목적지 IP 와 통신했는가
어떤 포트와 프로토콜을 사용했는가
트래픽이 허용 되었는가, 거부 되었는가
어느 네트워크 인터페이스에서 통신이 발생하는가
어느 방향으로 트래픽이 이동했는가
일정 시간 동안 몇 개의 패킷과 바이트가 전송되었는가

이벤트에 기록되는 정보(핵심 필드)

기본 출력 형식은 텍스트(공백을 구분자로)


// 실제로는 줄바꿈 없이 한 줄로 되어 있음
------ 필드 -----
{version} {account-id} {interface-id}
{srcaddr} {dstaddr}
{srcport} {dstport} {protocol} {packets} {bytes}
{start} {end}
{action} {log-status}

------ 실제 예시 로그 ------
2 123456789012 eni-0abc123
192.168.35.215 10.0.1.55
51515 22 6 10 1020
1722873600 1722873660
ACCEPT OK

필드 설명(예시 로그 기준)

필드명	값	의미
`version`	2	로그 형식 버전 (기본 형식 v2, 14개 필드)
`account-id`	123456789012	ENI 소유 AWS 계정 ID
`interface-id`	eni-0abc123	트래픽이 캡처된 ENI ID
`srcaddr`	192.168.35.215	출발지 IP
`dstaddr`	10.0.1.55	목적지 IP
`srcport`	51515	출발지 PORT
`dstport`	22	목적지 PORT
`protocol`	6	IANA 프로토콜 번호 (TCP:6, UDP:17, ICMP:1)
`packets`	10	집계 구간 동안 전송된 패킷 수
`bytes`	1020	집계 구간 동안 전송된 바이트 수
`start`	1722873600	트래픽 흐름 시작 시간 (Unix Epoch, 초)
`end`	1722873660	트래픽 흐름 종료 시간 (Unix Epoch, 초)
`action`	ACCEPT	보안 그룹/NACL 허용 여부 (ACCEPT / REJECT)
`log-status`	OK	로그 기록 상태 (OK, NODATA, SKIPDATA)

분석 목적에 따라 커스텀 필드 추가 가능 → 보안 관점에서 도움되는 필드

flow-direction - ingress / egress 방향 필터링(로그를 캡처한 ENI 기준)
pkt-srcaddr / pkt-dstaddr - 실제 패킷 IP(NAT/로드밸런서를 거치기 전의 원래 IP)
이때, 로그 분석을 위해 별도 파싱이 필요할 수 있음

로그 수집・저장 방법

S3 저장 - 로그를 장기 보존할 수 있고, 침해사고 발생 시 포렌식에 활용 및 Athena 분석 가능

로그 레코드를 파일로 집계하여 S3 버킷에 저장(기본 최대 집계구간은 10분)

CloudWatch - 로그 검색, Metric 필터, 알람 기능 제공

Flow Log 생성 시 목적지를 CloudWatch Logs 로 설정
CloudWatch 연동 시 CloudTrail 과 별도의 IAM Role 사용

Data Firehose - 지속적으로 생성되는 로그를 관리하고, 처리 대상 시스템으로 전달하는 데 유용

전송 파이프라인(저장소 X)
로그 형식 변환, 외부 SIEM 전송, 대규모 Flow Log 처리 시에 유리

SIEM 연동 - 일반적인 SecOps 환경에서 활용

탐지 가능한 위협

포트 스캔

의심 이벤트


동일 srcaddr -> 동일 dstaddr -> 다수 dstport
-> action = "REJECT" 급증

=> 포트 스캔 의심

여러 호스트 수평 스캔

의심 이벤트


동일 srcaddr -> 동일 dstport -> 여러 dstaddr 반복 접근

=> 수평 스캔 의심 # 공개된 호스트를 찾는 시도

무차별 대입 공격(Brute Force)

의심 이벤트


외부 srcaddr -> dstport IN (22, 3389) -> 반복 시도
-> action = "REJECT" 급증

=> 원격 접속 스캔/접근 시도 // 로그인 성공・실패 확인 불가(OS・인증 로그와 상관분석 필요)

C&C(C2) 통신

의심 이벤트


동일 dstaddr 로 규칙적 간격의 소량 통신
+ Threat Intelligence IoC 매칭
-> action = "ACCEPT"

=> 악성 IP 및 C2 통신 의심

데이터 유출

의심 이벤트 - flow-direction 커스텀 필드 활용


내부 서버 -> 외부 dstaddr + flow-direction = "egress"
+ bytes 비정상 급증

=> 데이터 유출 의심

측면 이동(Lateral Movement)

의심 이벤트


내부 srcaddr -> 내부 dstaddr(평소 통신이 없던 서브넷 간 연결)
+ SMB(445), RDP(3389), SSH(22) 포트

=> 측면 이동 의심

VPC Flow Logs 한계

페이로드가 없어, 패킷의 실제 내용을 모름

일부 트래픽을 기록하지 못함

AWS DNS 서버 트래픽, 인스턴스 메타데이터 접근 등

일정 집계 구간을 기준으로 레코드를 생성 → 로그 전달 지연

패킷을 실시간으로 탐지하는 데에는 부적합

트래픽양에 따라 비용이 많이 발생 - 로그를 쌓는 목적지에 따라 상이

필요한 구간만 선택적으로 켜서 관리

로그 레코드가 텍스트 포맷으로 되어 있어, 분석 환경에 따라 파싱 필요

Wazuh 는 기본적으로 VPC Flow Logs 파서 내장
단, 커스텀 필드를 사용할 경우 커스텀 디코더가 필요할 수 있음

🟡 WAF Logs

로그 개요

웹 애플리케이션으로 전달되는 HTTP/HTTPS 요청을 기록하고 분석하기 위한 애플리케이션 계층 보안 로그 - Payload 일부를 볼 수 있음

Web ACL 에 정의된 Rule 을 기반으로 요청을 처리(Allow・Block・Count・CAPTCHA・Challenge)

확인 가능한 행위

웹 공격 탐지 및 분석 - SQLi, XSS, Bot 등
공격자의 요청 패턴 분석

어떤 IP 가
어떤 URL 에
어떤 HTTP Method 로
어떤 Rule 에 의해
어떻게 처리 되었는지

보안 정책 효과 검증 - WAF Rule 이 정상적으로 동작 하는지 확인

이벤트에 기록되는 정보(핵심 필드)

기본 출력 형식은 JSON


"timestamp": 1722873600000, // 요청 발생 시간(Unix Epoch, 밀리초)
"formatVersion": 1, // 로그 형식 버전
"webaclId": "arn:aws:wafv2...", // 적용된 Web ACL
"terminatingRuleId": "BlockSQLInjection", // 요청을 최종 처리한 Rule
"terminatingRuleType": "REGULAR", // Rule 종류(REGULAR(사용자 정의) / MANAGED_RULE_GROUP(AWS 관리) / RATE_BASED(Rate Limit))
"action": "BLOCK", // WAF 처리 결과(ALLOW / BLOCK / CAPTCHA / CHALLENGE)
"httpSourceName": "ALB", // 보호 대상 서비스 유형(CF / ALB / APIGW / APPSYNC)
"httpSourceId": "arn:aws:elasticloadbalancing:...", // 해당 리소스의 식별자

"ruleGroupList": [], // 어떤 Rule Group 에서 탐지 했는지를 기록

"rateBasedRuleList": [], // 레이트 기반 규칙 정보(DDoS・Brute Force 탐지)

"nonTerminatingMatchingRules": [], // 매칭됐지만 요청을 종결시키지 않은 규칙(주로 COUNT 모드)

"httpRequest": { // HTTP 요청 내용
	"clientIp": "58.235.187.29", // 요청을 발생시킨 클라이언트 IP
	"country": "KR", // 요청 국가 정보
	"headers": [ // 요청 헤더 목록
		{
			"name": "Host",
			"value": "example.com"
		},
		{
			"name": "authorization",
			"value": "REDACTED"
		}
	],
	"uri": "/login", // 요청 URL 경로
	"args": "q=union+select+*+from+users", // 쿼리 스트링(공격 payload 분석)
	"httpVersion": "HTTP/1.1",
	"httpMethod": "GET", // HTTP 요청 방식(GET / POST / PUT / DELETE)
	"requestId": "12345678-1234-1234-1234-123456789012"
},
"labels": [] // WAF가 부여한 라벨(공격 유형 분류)

로그 수집・저장 방법

Web ACL 에서 Logging 기능을 활성화하여 로그를 저장

목적지에 지정하는 이름은 접두사 제약이 있음(aws-waf-logs-)

CloudWatch - 로그 검색, Metric 필터, 알람 기능 제공

Web ACL 에서 Logging 활성화 시에 목적지를 CloudWatch 로 설정

S3 저장 - 로그를 장기 보존할 수 있고, 침해사고 발생 시 포렌식에 활용 및 Athena 분석 가능

Data Firehose - 지속적으로 생성되는 로그를 관리하고, 처리 대상 시스템으로 전달하는 데 유용

전송 파이프라인(저장소 X)
실시간성이 높고, SIEM 연동과, 대량 로그 처리에 장점이 있음

탐지 가능한 위협

인젝션 공격(SQLi, XSS, Command Injection)


terminatingRuleId 필드에 매칭 + httpRequest.args 페이로드 확인

예시) ' OR 1=1 #, <script>alert(1)</script>, ;cat /etc/passwd

httpRequest.arg , httpRequest.url 필드에서 공격 페이로드를 확인할 수 있음

Path Traversal


terminatingRuleId 필드에 매칭 + httpRequest.args 페이로드 확인

예시) ../../../etc/passwd

Brute Force / Credential Stuffing


uri = /login or /api/auth + httpMethod: "POST" + 동일 IP 에서 반복 요청
+ terminatingRuleType: "RATE_BASED"

악성 Bot / Scraping


httpRequest.headers.User-Agent 부재 또는 비정상 + 인간적이지 않은 요청 간격

취약점 스캐닝


동일 clientIp -> 짧은 시간 내 다수의 서로 다른 url 요청
+ 존재하지 않는 경로 대량 요청 (/wp-admin, /.git/config, /.env)
+ httpRequest.headers.User-Agent: "sqlmap", "nikto", "nmap" // 스캐너 도구

Layer 7 DDoS


rateBasedRuleList 의 maxRateAllowed 초과
+ 동일 IP 또는 소수 IP 에서 대량 요청

WAF Logs 한계

HTTP POST body 내용은 기본적으로 로그에 남지 않아, 공격 패턴 및 파라미터 상세 분석에 제한적

요청에 포함된 개인정보, 토큰, 인증 헤더가 그대로 기록되어 민감 정보가 노출될 위험이 있음

별도의 REDACTED 처리 필수

🟢 DNS Query Log

로그 개요

VPC 내부 리소스가 수행하는 DNS Query 정보를 기록하고 분석하기 위한 네트워크 보안 로그

AWS Route 53 Resolver - Query Logging 을 통해 로그를 수집

확인 가능한 행위

내부 리소스(EC2 등)가 어떤 외부 도메인을 조회했는가

악성 도메인(C2 통신) 조회

DNS 터널링으로 인한 데이터 유출 행위

이벤트에 기록되는 정보(핵심 필드)

기본 출력 형식은 JSON → Amazon Route 53Resolver 쿼리 로깅 - Amazon Route 53
Resolver 쿼리 로깅 - Amazon Route 53
Route 53를 사용하여 도메인을 등록하고, 도메인이 호스팅된 리소스로 트래픽을 라우팅하고, 리소스의 상태를 확인할 수 있습니다. 또한 리소스의 상태에 따라 트래픽을 라우팅할 수도 있습니다. 이 가이드는 Route 53 콘솔을 사용하여 도메인을 등록하고, DNS를 구성하고, 상태 확인을 구성하는 방법을 설명합니다.
Amazon Route 53


"version": "1.100000", // Query Log 형식의 버전
"account_id": "123456789012", // VPC 를 생성한 AWS 계정의 ID
"region": "ap-northeast-2", // VPC 를 생성한 AWS 리전
"vpc_id": "vpc-123456", // 쿼리가 시작된 VPC 의 ID
"query_timestamp": "2026-08-06T16:30:00Z", // DNS 요청 시간(ISO 8601 형식, UTC)
"query_name": "malware-example.com", // 조회한 도메인 이름
"query_type": "A", // DNS 레코드 유형(A, AAAA, TXT, MX, CNAME 등)
"query_class": "IN", // 쿼리의 클래스
"rcode": "NOERROR", // DNS 쿼리에 대한 응답으로 반환한 DNS 응답 코드
"answers": [ // DNS 응답값
	{
		"Rdata": "203.0.113.55", // 쿼리에 대한 응답 -> VPC Resolver 반환 값
		"Type": "A", // 쿼리에 대한 응답 -> VPC Resolver 반환 하는 값의 DNS 레코드 유형
		"Class": "IN" // 쿼리에 대한 VPC Resolver 응답 클래스	
	}
],
"srcaddr": "192.168.35.250", // 쿼리가 시작된 호스트의 IP 주소
"srcport": "51234", // 쿼리가 시작된 인스턴스의 포트
"transport": "UDP", // DNS 쿼리를 제출하는데 사용되는 프로토콜(UDP/TCP)
"srcids": {
	"instance": // EC2 Instance ID
}

로그 수집・저장 방법

Route 53 Resolver 에서 Query Logging 을 활성화 하여 수집

CloudWatch Logs - Logs Insights 를 사용하여 로그를 분석하고 지표 및 경보 생성 가능

S3 저장 - 로그를 장기 보존할 수 있고, 침해사고 발생 시 포렌식에 활용 및 Athena 분석 가능

Data Firehose - 지속적으로 생성되는 로그를 관리하고, 처리 대상 시스템으로 전달하는 데 유용

전송 파이프라인(저장소 X)
실시간성이 높고, SIEM 연동과, 대량 로그 처리에 장점이 있음

탐지 가능한 위협

C&C(C2) 통신


query_name 의 도메인 이름이 알려진 C2 도메인 IoC 와 매칭
+ 동일 srcaddr 에서 규칙적 간격 반복 조회

피싱 도메인 조회


query_name 의 도메인 이름이 정상 도메인과 유사한 타이포스쿼팅

예시) never.com, gogle.com

DNS 터널링


query_type: "TXT" or "NULL" 대량 조회
+ query_name 이 비정상적으로 길고 인코딩된 형태 // a8s92jd92jd92jd92jd92.example.com
+ 동일 상위 도메인에 대한 서브도메인 대량 조회

=> 은밀한 데이터 유출

Cryptojacking


알려진 채굴 풀 도메인 조회

예시) *.minexmr.com, *.nanopool.org, pool.supportxmr.com

DGA 탐지


rcode: "NXDOMAIN" 급증 // 도메인 이름을 찾을 수 없을 때 반환되는 응답 코드
+ query_name 이 무작위 문자열
+ 짧은 시간 내 다수의 서로 다른 도메인 조회 // 대량 Query

=> C2 서버 통신

DNS Query Log 한계

DNS Resolver 가 응답을 이미 캐시하고 있는 경우, 쿼리가 누락될 수 있음

TTL 내 재조회는 로그에 기록되지 않음

일반적인 도메인 기반 통신에서 DNS Query 가 다량 발생할 수 있어 로그 볼륨과 비용 부담이 있음

EC2 가 8.8.8.8 같은 외부 DNS 직접 지정할 경우 로그에 남지 않음 → 탐지 우회 가능성

🛠️ SecOps 시스템(AWS)

🔴 CWPP (Cloud Workload Protection Platform)

클라우드 환경에서 실행되는 워크로드(EC2, Container, Serverless 함수 등)를 보호하기 위해 내부 위협을 감지하고 제거하는 보안 솔루션

💁 실행 중인 서버와 애플리케이션이 공격 받고 있는지 감지하고 차단

위협 탐지, 런타임 보호, 취약점 관리 기능을 제공

1️⃣ GuardDuty - 위협 탐지, 런타임 보호

AWS 시스템에서 발생하는 로그와 이벤트를 기반으로 악성 활동과 비정상 행위를 자동으로 탐지해주는 관리형 위협 탐지 서비스 - 별도 Agent가 필요 없음(기본 탐지의 경우) - 기본 비용 발생

기본 탐지 - 분석에 활용하는 기본 데이터 소스(로그)

CloudTrail 관리 이벤트, VPC Flow Logs, DNS Query Log
WAF Logs 는 분석하지 못함 → 애플리케이션 계층 위협을 AWS Native 탐지로 커버 불가

→ SIEM 에서 커스텀 룰로 분석 필요

GuardDuty 만 활성화 하면, 위 로그를 자동으로 분석하여 파인딩 → 탐지결과를 보여줌(JSON)


Finding(탐지결과) 구조 - 위협목적(what):대상리소스(where)/위협이름(how).변종!아티팩트

// EC2 서버에 백도어가 C&C 서버와 통신 시도 (VPC Flow Log 기반)
Backdoor:EC2/C&CActivity.B
Severity:High (Low / Medium / High / Critical)

// EC2 서버에 백도어가 C&C 서버와 통신 시도 (DNS Query Log 기반)
Backdoor:EC2/C&CActivity.B!DNS
Severity:High

Extended Threat Detection - GuardDuty 활성화 시 기본 활성화(추가 비용 X)

AWS 계정 내에서 데이터 소스, 다양한 유형의 AWS 리소스 및 시간에 걸쳐 발생하는 Multi-Stage Attack 을 자동으로 탐지
여러 이벤트와 Finding 을 상관분석하여 Attack Sequence Finding 생성

Protection Plans(확장 보호 플랜)을 지원 → 탐지 범위는 넓어지나(+ Data Event 등), 비용 증가 리스크

S3 Protection : S3 버킷 활동 모니터링, CloudTrail 이벤트 분석 → S3 데이터에 대한 Potential Threat 탐지

EKS Protection : EKS 감사 로그 분석을 통해 EKS 클러스터에 대한 위협 탐지 커버리지 제공

Runtime Monitoring : EKS, ECS, EC2 워크로드에서 런타임 이벤트를 분석 → OS 레벨 위협 탐지

Malware Protection : EBS 볼륨과 S3 객체를 스캔하여 EC2 인스턴스, 컨테이너 워크로드, S3 버킷의 Malware 위협을 식별

RDS Protection : Aurora / RDS 데이터베이스의 로그인 활동을 분석・프로파일링 → 잠재적 접근 위협 탐지

Lambda Protection : Lambda 함수 실행 시 생성되는 네트워크 활동 로그 모니터링 → 서버리스 환경에 특화된 위협 식별

탐지 결과 예시


// IAM User/Role 이 버킷 정책을 변경해 모든 AWS 사용자에게 공개 접근 허용
Policy:S3/BucketPublicAccessGranted
Severity:High

// 특정 IAM User/Role 이 평소 접근 패턴과 다르게 행동(다량의 GetObject or 짧은 시간 안에 비정상적으로 많은 데이터를 내려받음)
Exfiltration:S3/AnomalousBehavior
Severity:High

// EC2 인스턴스에 연결된 EBS 볼륨에서 악성 파일이 탐지
Execution:EC2/MaliciousFile
Severity:탐지 위협에 따라 다름

💁 확장 보호 플랜을 활성화하면, Extended Threat Detection 이 상관분석할 수 있는 이벤트 및 신호의 범위가 확대됨

GuardDuty Finding Type

GuardDuty finding types - Amazon GuardDuty

Use Amazon GuardDuty to continuously monitor the security of your AWS environment.

https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html

2️⃣ Inspector - 취약점 관리

AWS 환경에서 실행되는 리소스(EC2 인스턴스, ECR 컨테이너 이미지, Lambda 함수 등)를 자동으로 검색 및 스캔하는 취약점 관리 서비스

소프트웨어 취약성 식별 - CVE 를 통한 취약성 평가
의도치 않은 네트워크 노출 식별 - 외부에서 접근 가능한 SSH 나 HTTP 등 사용되는 포트를 검출하여 평가

리소스 유형별 스캔 방식이 다름

대상	주요 검사
EC2	OS・애플리케이션 패키지 취약점, 네트워크 도달 가능성(트래픽 탐지 X, 네트워크 설정상 해당 포트에 도달할 수 있는지 검사)
ECR	ECR 에 등록되는 컨테이너 이미지 패키지 취약점
Lambda 표준	Lambda 함수와 Layer 에 포함된 애플리케이션 종속성 취약점
Lambda 코드	소스코드 수준 보안 취약점, 사용자 정의 애플리케이션 코드 취약점 (Lambda 표준 스캔이 활성화되어 있어야 함)
Code Security	자사 애플리케이션 코드, 타사 애플리케이션 종속성, IaC 취약점 (코드 리포지토리에서 확인)

스캔 결과 유형

패키지 취약성 - CVE 에 노출된 소프트웨어 패키지를 식별
코드 취약성 - 암호화 누락, 데이터 유출, 인젝션 결함, 취약한 암호화 등 악용될 수 있는 코드라인 식별
네트워크 연결성 - EC2 인스턴스에 네트워크 접근 가능성을 식별(외부/다른 네트워크에서 접근 가능한지)

스캔 결과는 Finding(취약점, 권장 조치 방법 포함) 으로 구성, 콘솔의 대시보드 및 ListFindings API 를 통해 확인할 수 있음

Security Hub 활용 시, 다른 AWS 보안 서비스의 Finding 과 상관 분석 가능
EventBridge 및 Lambda 를 통해 자동 대응 프로세스 구축도 가능

Finding Severity levels →

Amazon Inspector –Amazon Inspector 조사 결과의 심각도 수준 이해 - Amazon Inspector –

Amazon Inspector 조사 결과의 심각도 수준 이해 - Amazon Inspector –

Amazon Inspector는 워크로드를 자동으로 검색하고 소프트웨어 취약성 및 의도하지 않은 네트워크 노출이 있는지 지속적으로 스캔하는 취약성 관리 서비스입니다.

🟠 CSPM (Cloud Security Posture Management)

클라우드 인프라 전반의 보안 설정 상태(Configuration)를 점검하고 보안 상태에 대한 가시성을 제공하여 보안 상태를 개선하기 위한 보안 솔루션

💁 클라우드가 안전하게 구성되어 있는지를 지속적으로 점검하고 개선 방향을 제시

설정 오류 탐지, 컴플라이언스 매핑, 위험 우선순위 가이드, 자산 인벤토리 기능을 제공

1️⃣ Security Hub - 보안 상태 통합 대시보드

여러 AWS 보안 서비스(GuardDuty, Inspector, Macie 등) 에서 생성된 보안 Finding 을 중앙 집중화하여 통합 관리하는 CSPM 서비스 - 외부 보안 서비스도 연결 가능

AWS 계정과 리소스가 보안 모범 사례를 준수하고 있는지 확인 가능(컴플라이언스 매핑) - 다수 제어가 AWS Config 의 리소스 기록을 사용(AWS Config 리소스 기록 활성화가 선행되어야 함)

AWS Foundational Security Best Practices
CIS AWS Foundations Benchmark
PCI DSS
NIST 관련 보안 표준
AWS 제공 기타 보안 표준

중앙 통합 대시보드 - 여러 보안 서비스의 Finding 을 통합하여 대시보드에 보여줌(원본 로그를 보는 것이 아님)

ASFF 라는 공통 Finding Format 을 사용 - 각 보안 서비스 Finding 의 필드명과 구조의 차이를 해소

ASFF (AWS Security Finding Format) - 공식 문서 참고

대표적인 ASFF 필드

필드	설명
`AwsAccountId`	Finding 이 발생한 AWS 계정
`Region`	발생 리전
`ProductArn`	Finding 을 생성한 보안 서비스
`Types`	Finding 유형
`Severity`	심각도
`Resources`	영향을 받는 AWS 리소스
`Title`	Finding 제목
`Description`	상세 설명
`Compliance`	보안 표준 준수 여부
`Workflow`	조사 및 처리 상태
`RecordState`	활성 또는 보관 상태
`CreatedAt`	Finding 이 나타내는 보안 문제 또는 이벤트가 생성된 시점
`UpdatedAt`	Finding 제공자가 Finding 레코드를 마지막으로 갱신한 시점

활성화된 보안 제어의 통과 및 실패 상태를 기반으로 보안 점수를 퍼센트로 제공

전체 보안 상태, 표준별 준수 수준, 실패한 제어, 영향받는 리소스, 개선 우선순위 등을 확인할 수 있음

EventBridge 사용 시, 결과에 대해 자동 대응이 가능

Lambda 함수 호출
SNS 서비스를 통한 알림
Third-party 도구로 Finding 전송

Security Hub 한계

CloudTrail, VPC Flow Logs, WAF Logs, DNS Query Log 와 같은 원본 로그를 수집하지 못함
로그 검색 및 정교한 상관분석, 포렌식 기능이 제한됨 → SIEM 구축 필요

2️⃣ Config

AWS 리소스의 구성 상태를 지속적으로 관리하고 기록 및 평가하는 서비스 → 감사, 변경사항 확인 목적

리소스의 구성이 변경되면 Configuration Item 을 생성하여 해당 시점의 리소스 상태를 기록

History 를 통해 설정이 변경된 시점을 추적할 수 있음(현재 상태, 과거 상태, 변경 이력)

핵심 보안 기능

AWS 리소스가 Config Rule 을 준수하는지 평가하여 결과를 보여줌
Config Rule 은 AWS 가 제공하는 Managed Rule, 사용자가 정의하는 Custom Rule 이 있음

Config 가 기록하는 데이터 → AWS 리소스 설정 데이터

데이터	내용
Configuration Item	특정 시점의 리소스 구성
Configuration History	시간에 따른 구성 변경 이력(S3 에 저장해서 보관할 수 있음)
Configuration SnapShot	전체 리소스 구성 상태(S3 에 저장해서 보관할 수 있음)
Resource Relationship	리소스 간 연결 관계
Compliance Result	Rule 평가 결과

탐지 가능한 위협 → Misconfiguration, 보안 정책 미준수

Security Group 과도한 공개
S3 Public Access 허용
EBS, RDS, S3 암호화 미적용
IAM / Access Key 정책 위반
WAF 미적용
Tag 정책 위반
…

Config 한계

사용자 행위 분석의 한계가 있음 → History 로 구성 상태 변경 이력을 봐도, 누가? 왜? 변경했는지 모름

CloudTrail 연결 필요

🧐 Config 는 Rule 준수 여부를 판정해주는 엔진, Security Hub 는 판정 결과에 심각도・컴플라이언스 매핑・교정 가이드를 Wrapping 하여 Finding 으로 제시해주는 대시보드

➡️ Security Hub(집계・해석), Config(추적)

🟡 SIEM (Security Information and Event Management)

클라우드, 서버, 네트워크, 애플리케이션 및 보안 솔루션에서 발생하는 다양한 로그와 보안 이벤트를 중앙 수집하고 분석하는 통합 보안 솔루션

수집된 로그/이벤트 간의 연관성을 분석하여 비정상적인 패턴이나 침해사고 조사를 가능하게 함
수집되는 로그 소스마다 데이터 구조가 달라 각 로그 소스별 의미있는 필드를 파싱 → 이후, 정규화를 통해 공통 필드로 관리

SIEM 플랫폼에서 전체 보안 이벤트를 확인할 수 있음(대시보드 제공) → SIEM 을 사용하는 이유

로그 검색 및 분석
상관 분석(제일 핵심), 여러 로그/이벤트의 연관성 분석을 통해 타임라인 생성(시나리오 탐지)
탐지 룰 적용 → 알림과 연계(자동 대응도 가능)
TI 를 통한 IoC 비교도 가능

SIEM 수집 로그

Cloud 로그, 서버/OS 로그, 네트워크 보안 로그 등 연계된 모든 로그를 수집할 수 있음
AWS 보안 시스템의 Finding 도 수집 가능

✅ SIEM 의 탐지 품질은 수집 로그, TI, 탐지룰 설계에 따라 달라짐

1️⃣ Wazuh - Open Source

엔드포인트와 클라우드 환경의 보안 데이터를 수집・분석하는 무료 오픈소스 보안 플랫폼 - 완성형 SIEM/XDR 서비스

구성

Agent - 엔드포인트 로그, 파일, 프로세스, 설정, 취약점 정보 수집
Server - Decoder 와 Rule 을 이용해 이벤트를 분석하고 Alert 생성
Indexer - Alert 를 JSON 문서로 인덱싱・저장하고 검색 기능 제공
Dashboard - Alert 분석, 시각화, 위협 헌팅 및 에이전트 관리

AWS 로그 연동이 쉬움

AWS S3 모듈을 내장하고 있어, S3에 저장된 CloudTrail, VPC Flow Logs, WAF Logs 등의 AWS 로그를 가져옴

자체 XML 포맷의 탐지 Rule 사용

2️⃣ OpenSearch Service - AWS Native

AWS 및 외부 보안 로그를 수집・검색・상관분석할 수 있는 관리형 로그 분석 플랫폼

Sigma 탐지 룰을 제공, 커스텀 룰 작성 가능

완성형 SIEM 솔루션이 아님 → 사용자가 파이프라인 설계 필요

Security Analytics 를 통해 보안 로그를 분석하고 Finding 과 Alert 를 생성
기본 Log Type Mapping 과 Sigma Rule 을 제공하지만, 로그 수집・정규화・상관분석・알림・대응 파이프라인은 사용자 환경에 맞게 구성 필요

엔드포인트 Agent 가 제공되지 않아 애플리케이션 log, OS log 등 엔드포인트 내부 분석 필요 시 별도 로그 수집기 필요

💁 SIEM 선택

엔드포인트 보안과 클라우드 로그를 통합 분석하는 경우 Wazuh 가 적합

AWS 로그 만을 상관분석 하는 목적이면 OpenSearch Service 를 사용해도 적절함

🟢 SOAR (Security Orchestration, Automation and Response)

SIEM, AWS 보안 서비스 등에서 발생한 알림 및 Finding 을 입력 소스로 받아 보안 운영 및 사고 대응을 자동화하고 조율하는 보안 솔루션

SIEM 이 위협을 찾으면 SOAR 가 대응

주요 기능

Orchestration - 서로 다른 보안 시스템을 하나의 Workflow 로 연결하여 자동화
Automation - 단순 반복 작업을 자동화 → 인간 피로도 감소
Response - 핵심 목적, 플레이북에 따라 사고 대응 수행

일반적인 Workflow

Alert 수집 → Enrichment → Triage/판단 → Playbook 대응 → Case 관리

단계	내용
Alert 수집	SIEM Alert
Enrichment	TI 조회, IoC 평판 확인
Triage/판단	정・오탐 여부, 심각도 수준, 자동대응 여부
Playbook 대응	사전 정의된 Playbook 에 따라 자동 또는 반자동 대응(고위험, 담당자 승인)
Case 관리	대응 과정과 결과를 Case로 기록 관리(IoC, Timeline 등)

AWS 네이티브 서비스로 SOAR Workflow 를 구성하려면

Security Hub(Finding 집계), EventBridge(트리거 생성), Step Functions(Orchestration), System Manager Automation(플레이북 대응), SNS(담당자 알림) 서비스 활용
케이스 관리는 별도 오픈소스 활용 → TheHive / DFIR・IRIS

Native 구성의 경우, AWS 내부 보안 이벤트에 대한 대응에는 강점이 있음